Groupe de travail Réseau	ANSI X3S3.3 86-118	
Request for Comments : 995	ISO TC97/SC6/N 4053	
Traduction Claude Brière de L'Isle	avril 1986	

Protocole d'échange d'informations d'acheminement entre système d'extrémité et système intermédiaire à utiliser conjointement avec la norme ISO 8473

Source :   ISO/TC 97/SC6/WG2,  Projet 97.6.41

Le présent document est une étape du développement de SC6/N3862, édité pour incorporer les commentaires des organisations membres et être discuté à la réunion de Florence du SC6/WG2. Conformément à la recommandation 5 de cette réunion, les commentaires provenant des organisations membres sur ce texte révisé seront discutés à la réunion de Tokyo du SC6 et des groupes de travail.

Table des matières
1	Introduction
2	Domaine d'application
3	Références
4	Définitions
4.1	Définitions du modèle de référence
4.2	Définitions de l'architecture de couche réseau
4.3	Définitions d'adressage de couche réseau
4.4	Définitions de réseau de zone locale
4.5	Définitions additionnelles
5	Symboles et abréviations
5.1	Unités de données
5.2	Unités de données de protocole
5.3	Champs d'unités de données de protocole
5.4	Paramètres
5.5	Divers
6	Vue d'ensemble du protocole
6.1	Informations fournies par le protocole
6.2	Sous-ensembles du protocole
6.3	Adressage
6.4	Service sous-jacent supposé par le protocole
6.4.1	Adresses de sous-réseau
6.4.2	Données d'utilisateur de sous-réseau
6.5	Service supposé à partir de l'environnement local
6.6	Types de sous-réseau
6.6.1	Sous-réseaux en point à point
6.6.2	Sous-réseaux de diffusion
6.6.3	Sous réseaux de topologie générale
7	Fonctions du protocole
7.1	Temporisateurs du protocole
7.1.1	Temporisateur de configuration
7.1.2	Temporisateur de garde
7.2	Fonction de rapport de configuration
7.2.1	Rapport de configuration par les systèmes d'extrémité
7.2.2	Rapport de configuration par les systèmes intermédiaires
7.3	Fonction d'enregistrement de configuration
7.4	Fonction de purge d'ancienne configuration
7.5	Fonction d'interrogation de configuration
7.6	Fonction de réponse de configuration
7.7	Fonction de demande de redirection
7.8	Fonction d'enregistrement de redirection
7.9	Fonction de rafraîchissement de redirection
7.10	Fonction de purge d'ancienne redirection
7.11	Détection d'erreur d'en-tête de PDU
7.12	Classification des fonctions
8	Structure et codage des PDU
8.1	Structure
8.2	Partie fixe
8.2.1	Généralités
8.2.2	Identifiant de protocole de couche réseau
8.2.3	Indicateur de longueur
8.2.4	Extension d'identifiant de version/protocole
8.2.5	Code de type
8.2.6	Temps de garde
8.2.7	Somme de contrôle de PDU
8.3	Partie d'adresse réseau
8.3.1	Généralités
8.3.2	Codage des NPAI
8.3.3	Paramètres d'adresse de source pour PDU ESH
8.3.4	Paramètre Titre d'entité réseau pour PDU ISH
8.3.5	Paramètre d'adresse de destination pour PDU RD
8.4	Partie adresse de sous-réseau
8.4.1	Paramètre d'adresse de sous-réseau pour la PDU RD
8.5	Partie options
8.5.1	Généralités
8.5.2	Sécurité
8.5.3	Maintenance de la qualité de service
8.5.4	Priorité
8.6	PDU de Hello de système d'extrémité (ESH)
8.6.1	Structure
8.7	PDU de Hello de système intermédiaire (ISH)
8.7.1	Structure
8.8	PDU Redirect (RD)
8.8.1	Structure
9	Description formelle
10	Conformité
Annexe A	Prise en charge du matériel technique
A.1	Utilisation des temporisateurs
A.1.1	Exemple de temporisateur de garde pour la redirection de chemin
A.1.2	Exemple de temporisateur de garde pour les informations de configuration
A.2	Rafraîchissement et fin de temporisation des informations de redirection
A.3	Considérations pour l'initialisation du système
A.4	Optimisations pour la purge des redirections

1	Introduction

Le présent protocole fait partie d'un ensemble de normes internationales produites pour faciliter l'interconnexion de systèmes ouverts. L'ensemble de normes couvre les services et protocoles nécessaires pour réaliser une telle interconnexion.

Le présent protocole est positionné par rapport aux autres normes en rapport par les couches définies dans le modèle de référence pour l'interconnexion des systèmes ouverts (ISO 7498) et par la structure définie dans l'organisation interne des couches de réseau (DIS 8648). En particulier, c'est un protocole de la couche Réseau. Ce protocole permet aux systèmes d'extrémité et aux systèmes intermédiaires d'échanger des informations de configuration et d'acheminement pour faciliter le fonctionnement des fonctions d'acheminement et de relais de la couche Réseau.

Les aspects de la couche Réseau qui sont concernés par la communication entre systèmes d'extrémité et systèmes intermédiaires sur le même sous-réseau sont dans une large mesure séparables des aspects concernés par la communication entre les systèmes intermédiaires qui connectent plusieurs sous-réseaux. Ce protocole ne s'adresse qu'aux premiers aspects. Il sera amélioré de façon significative par le fonctionnement coopératif d'un protocole supplémentaire qui traite de l'échange des informations d'acheminement entre les systèmes intermédiaires, mais est utile, qu'un tel protocole supplémentaire soit disponible ou non.

Le présent protocole apporte des solutions aux problèmes pratiques suivants :

1.	Comment les systèmes d'extrémité découvrent-ils l'existence et l'accessibilité des systèmes intermédiaires qui peuvent acheminer les NPDU à destination sur des sous-réseaux autres que celui ou ceux auxquels le système d'extrémité est directement connecté ?

2.	Comment les systèmes d'extrémité découvrent-ils l'existence et l'accessibilité des autres systèmes d'extrémité sur le même sous-réseau (lorsque l'examen direct de l'adresse NSAP de destination ne fournit pas d'information sur le sous-réseau de destination) ?

3.	Comment les systèmes intermédiaires découvrent-ils l'existence et l'accessibilité des systèmes d'extrémité sur chacun des sous-réseaux auxquels ils sont directement connectés ?

4.	Comment les systèmes d'extrémité décident-ils quel système intermédiaire utiliser pour transmettre les NPDU à une destination particulière lorsque plus d'un système intermédiaire est accessible ?

Le protocole suppose que :

1.	L'acheminement vers une adresse de point de rattachement d'un sous-réseau (SNPA) spécifié sur le même sous-réseau est traité de façon satisfaisante par le sous-réseau lui-même.

2.	Le sous-réseau n'est cependant pas capable d'acheminer sur une base globale en utilisant la seule adresse NSAP pour réaliser la communication vers une destination demandée.

Note :	Par conséquent, il n'est pas possible d'utiliser une communication de couche Application pour mener à bien les fonctions de ce protocole.

Le protocole est sans connexion, et il est conçu pour :

1.	minimiser la quantité d'informations d'état a priori nécessitées par les systèmes d'extrémité avant qu'ils puissent commencer à communiquer avec les autres systèmes d'extrémité ;

2.	minimiser la quantité de mémoire nécessaire pour mémoriser les informations d'acheminement dans les systèmes d'extrémité ;

3.	minimiser la complexité de calcul des algorithmes d'acheminement des systèmes d'extrémité.

Le protocole est aussi conçu pour fonctionner en étroite conjonction avec le protocole pour la fourniture du service réseau en mode sans connexion (ISO 8473). Comme les styles d'acheminement sont généralement en rapport étroit avec les styles de communication, les informations que fournit ce protocole aux systèmes d'extrémité et systèmes intermédiaires peuvent être ou non des informations appropriées pour la prise en charge des fonctions d'acheminement si un protocole de couche Réseau autre que ISO 8473 est utilisé.

2	Domaine d'application

La présente Norme internationale spécifie un protocole qui est utilisé par les entités de couche Réseau qui fonctionnent avec ISO 8473 dans les systèmes d'extrémité et les systèmes intermédiaires (qui sont mentionnées ici respectivement comme ES et IS) pour entretenir les informations d'acheminement. Le protocole décrit ici s'appuie sur la fourniture d'un service sous-jacent en mode sans connexion.

La présente norme spécifie :

a)	les procédures de transmission des informations de configuration et d'acheminement entre entités du réseau qui résident dans les systèmes d'extrémité et entités du réseau qui résident dans les systèmes intermédiaires ;

b)	le codage des unités de données de protocole utilisées pour la transmission des informations de configuration et d'acheminement ;

c)	les procédures pour l'interprétation correcte des informations de contrôle du protocole ;

d)	les exigences fonctionnelles pour les mises en œuvre qui revendiquent la conformité à la présente norme.

Les procédures sont définies en termes :

a)	d'interactions entre entités réseau de système d'extrémité et de système intermédiaire à travers l'échange d'unités de données de protocole ;

b)	d'interactions entre une entité réseau et le fournisseur du service sous-jacent à travers l'échange de primitives de service de sous-réseau.

Le présent protocole ne spécifie aucun élément de protocole ou algorithme pour faciliter l'acheminement et le relais entre les systèmes intermédiaires. De telles fonctions sont intentionnellement en dehors du domaine d'application du présent protocole.

3	Références

ISO 7498	Systèmes de traitement de l'information --- Interconnexion des systèmes ouverts – Modèle de référence de base

DIS 7498/DAD1	Systèmes de traitement de l'information --- Interconnexion des systèmes ouverts - Addendum à ISO 7498 couvrant la transmission en mode sans connexion

ISO 8348	Systèmes de traitement de l'information --- Télécommunications et échanges d'informations entre systèmes – Définition du service de réseau

ISO 8348/AD1	Systèmes de traitement de l'information --- Télécommunications et échanges d'informations entre systèmes - Addendum à la définition du service de réseau couvrant la transmission en mode sans connexion

ISO 8348/DAD2	Systèmes de traitement de l'information --- Télécommunications et échanges d'informations entre systèmes - Addendum à la définition du service de réseau couvrant l'adressage de couche Réseau

ISO 8473	Systèmes de traitement de l'information --- Télécommunications et échanges d'informations entre systèmes – Protocole pour la fourniture du service réseau sans connexion

DIS 8648	Systèmes de traitement de l'information --- Télécommunications et échanges d'informations entre systèmes - Organisation interne de la couche Réseau

SC21/N965	Cadre de la gestion OSI --- Septième projet

DIS 8802	Réseaux de zone locale

4	Définitions
4.1	Définitions du modèle de référence

Le présent document utilise les concepts suivants, définis dans la norme ISO 7498 :

(a)	couche Réseau
(b)	point d'accès de service réseau
(c)	adresse de point d'accès de service réseau
(d)	entité réseau
(e)	acheminement
(f)	protocole réseau
(g)	relais de réseau
(h)	unité de données de protocole réseau

4.2	Définitions de l'architecture de couche réseau

Le présent document utilise les concepts suivants, d'après le DIS 8648, Organisation interne de la couche Réseau :

(a)	sous-réseau
(b)	système d'extrémité
(c)	système intermédiaire
(d)	service de sous-réseau
(e)	protocole d'accès de sous-réseau
(f)	protocole de convergence indépendant du sous-réseau

4.3	Définitions d'adressage de couche réseau

Le présent document utilise les concepts suivants, d'après le DIS 8348/DAD2, Addendum à la définition du service de réseau couvrant l'adressage de couche Réseau :

(a)	adresse de sous-réseau
(b)	point de rattachement de sous-réseau

4.4	Définitions de réseau de zone locale

Le présent document utilise les concepts suivants, d'après le DIS 8802, Réseaux de zone locale :

(a)	adresse de diffusion groupée
(b)	support de diffusion

4.5	Définitions additionnelles

Pour les besoins du présent document, on appliquera les définitions suivantes :

Configuration : Collection des systèmes intermédiaires et d'extrémité rattachés à un seul sous-réseau, définie en termes de types de systèmes, d'adresses NSAP présentes, d'entités réseau présentes, et de correspondance entre systèmes et adresses SNPA.

Titre d'entité réseau : Identifiant pour une entité réseau qui a la même syntaxe abstraite qu'une adresse NSAP, et qui peut être utilisée pour identifier sans ambiguïté une entité réseau dans un système intermédiaire ou d'extrémité.

5	Symboles et abréviations
5.1	Unités de données

PDU	(Protocol Data Unit) unité de données de protocole
SNSDU	(Subnetwork Service Data Unit) unité de données de service de sous-réseau

5.2	Unités de données de protocole

ESH PDU	(système d'extrémité Hello Protocol Data Unit) unités de données de protocole Hello de système d'extrémité
ISH PDU	(système intermédiaire Hello Protocol Data Unit) unités de données de protocole Hello de système intermédiaire
RD PDU	(Redirect Protocol Data Unit) unités de données de protocole Redirect

5.3	Champs d'unités de données de protocole

NPID	(Network Layer Protocol Identifier) identifiant de protocole de couche Réseau
LI	(Length Indicator) indicateur de longueur
V/P	(Version/Protocol Identifier Extension) extension d'identifiant de version/protocole
TP	Type
CS	(Checksum) somme de contrôle
NETL	(Network entity Title Length) longueur de titre d'entité réseau
NET	(Network entity Title) titre d'entité réseau
DAL	(Destination Address Length) longueur d'adresse de destination
DA	(Destination Address) adresse de destination
SAL	(Source Address Length) longueur d'adresse de source
SA	(Source Address) adresse de source
BSNPAL	(SN Address Length of better route to destination) longueur d'adresse de sous-réseau du meilleur chemin à dest.
BSNPA	(SN Address of better route to destination) adresse du sous-réseau du meilleur chemin à destination
HT	(Holding timer) temporisateur de garde

5.4	Paramètres

CT	(Configuration Timer) temporisateur de configuration
RT	(Redirect Timer) temporisateur de redirection

5.5	Divers

ES	(système d'extrémité) système d'extrémité
IS	(système intermédiaire) système intermédiaire
SN	(Subnetwork) sous-réseau
SNACP	(Subnetwork Access Protocol) protocole d'accès de sous-réseau
SNICP	(Subnetwork Independent Convergence Protocol) protocole de convergence indépendante du sous-réseau

6	Vue d'ensemble du protocole
6.1	Informations fournies par le protocole

Le présent protocole fournit deux types d'informations aux entités de réseau qui prennent en charge son fonctionnement :
a)	Informations de configuration 
b)	Informations de redirection  de chemin

Les informations de configuration permettent aux systèmes d'extrémité de découvrir l'existence et l'accessibilité des systèmes intermédiaires et permettent aux systèmes intermédiaires de découvrir l'existence et l'accessibilité des systèmes d'extrémité. Ces informations permettent aux ES et aux IS rattachés au même sous-réseau de découvrir de façon dynamique leur existence et disponibilité réciproque, éliminant ainsi le besoin d'une intervention manuelle aux ES et IS pour établir l'identité des entités réseau qui peuvent être utilisées pour acheminer les NPDU.

Les informations de configuration permettent aussi aux systèmes d'extrémité d'obtenir des informations sur chacun d'entre eux en l'absence d'un système intermédiaire disponible.

Note : Le terme "informations de configuration" n'est pas entendu dans le sens large de configuration tel qu'utilisé dans le contexte de la gestion du système OSI. Ici, il s'agit plutôt des seules fonctions spécifiquement définies.

Les informations de redirection de chemin permettent aux systèmes intermédiaires d'informer les systèmes d'extrémité de meilleurs chemins (potentiels) à utiliser lors de la transmission des NPDU à une destination particulière. Un meilleur chemin pourrait être un autre IS sur le même sous-réseau que l'ES, ou l'ES de destination lui-même, si il est sur le même sous-réseau que l'ES de source. Permettre aux IS d'informer les ES des chemins minimise la complexité des décisions d'acheminement dans les systèmes d'extrémité et améliore les performances parce que les ES peuvent faire usage du meilleur IS ou accès de sous-réseau local pour les transmissions ultérieures.

6.2	Sous-ensembles du protocole

Une entité réseau peut choisir de prendre en charge les informations de configuration, les informations de redirection de chemin, ni l'une ni l'autre, ou les deux. Si les informations de configuration sont prises en charge, il n'est pas exigé qu'elles soient employées sur tous les sous-réseaux auxquels l'entité réseau est rattachée.

6.3	Adressage

Les paramètres Adresse de source et Adresse de destination auxquels on se réfère dans la présente Norme internationale sont les adresses de point d'accès de service réseau de l'OSI. La syntaxe et la sémantique d'une adresse de point d'accès de service réseau de l'OSI sont décrites dans un document séparé, ISO 8348/DAD2, Addendum à la définition du service de réseau couvrant l'adressage de couche Réseau.

6.4	Service sous-jacent supposé par le protocole

Le service sous-jacent requis pour la prise en charge de ce protocole est défini par les primitives du Tableau 1.

     _________________________________________________________________
     |    SN_UNITDATA          .Request    | SN_Destination_Address, |
     |                         .Indication | SN_Source_Address,      |
     |                                     | SN_Quality_of_Service,  |
     |                                     | SN_Userdata             |
     |_____________________________________|_________________________|

Tableau 1 : Primitives de service pour service sous-jacent

Note : Ces primitives de service sont utilisées pour décrire l'interface abstraite qui existe entre la machine de protocole et un sous-réseau réel sous-jacent ou une fonction de convergence dépendante du sous-réseau qui fonctionne sur un sous-réseau réel ou une liaison de données réelle pour fournir le service sous-jacent requis.

6.4.1	Adresses de sous-réseau
Les adresses de source et de destination spécifient les points de rattachement à un ou des sous-réseaux publics ou privés impliqués dans la transmission (appelés points de rattachement de sous-réseau, ou SNPA). Les adresses de sous-réseau sont définies dans la définition de service de chaque sous-réseau individuel. Ce protocole a été conçu pour tirer parti des sous-réseaux qui prennent en charge la diffusion, la diffusion groupée, ou d'autres formes d'adressage multi destination pour la transmission multilatérale. On suppose que le paramètre SN_Destination_Address peut prendre une des adresses multi-destination suivantes en plus d'une adresse de destination unique normale.

Toute entité réseau de système d'extrémité

Toute entité réseau de système intermédiaire

Lorsque un sous-réseau réel ne prend pas en charge par nature la diffusion ou d'autres formes de transmission à des adresses multi-destination, une fonction de convergence peut être utilisée pour fournir la transmission multilatérale à ces adresses multi-destination.

Lorsque le paramètre SN_Destination_Address sur la demande SN_UNITDATA.Request est une adresse multi-destination, le paramètre SN_Destination_Address dans l'indication SN_UNITDATA.Indication correspondante doit être la même adresse multi-destination.

La syntaxe et la sémantique des adresses de sous-réseau, à part les propriétés décrites ci-dessus, ne sont pas définies dans la présente norme de protocole.

6.4.2	Données d'utilisateur de sous-réseau
SN_Userdata est un multiple ordonné d'octets, et est transféré de façon transparente entre les points de rattachement de sous-réseau spécifiés.

Le service sous-jacent est obligé de prendre en charge une taille d'unité de données de service d'au moins celle exigée pour faire fonctionner le protocole de fourniture de service réseau sans connexion (ISO 8473).

6.5	Service supposé à partir de l'environnement local

Un service de temporisateurs doit être fourni pour permettre à l'entité de protocole de programmer les événements.

Trois primitives sont associées au service S-TIMER :

1.	Demande S--TIMER,
2.	Réponse S--TIMER,
3.	Annulation S--TIMER.

La primitive Demande S--TIMER indique à l'environnement local qu'il devrait initialiser un temporisateur du nom spécifié et l'indexer et le maintenir pour la durée spécifiée par le paramètre de durée.

La primitive Réponse S--TIMER est initialisée par l'environnement local pour indiquer que le délai demandé par la primitive Demande S-TIMER correspondante est écoulé.

La primitive Annulation S--TIMER est une indication pour l'environnement local que le ou les temporisateurs spécifié devraient être annulés. Si le paramètre indexé n'est pas spécifié, tous les temporisateurs ayant le nom spécifié sont annulés ; autrement, le temporisateur de ce nom et index donné est annulé. Si aucun temporisateur ne correspond aux paramètres spécifiés, l'environnement local ne fait rien.

Les paramètres des primitives de service S--TIMER sont spécifiées au Tableau 2.

          ___________________________________________
         |                          |               |
         | S--TIMER     .Demande    | S-Temps,      |
         |                          | S-Nom,        |
         |                          | S-Indice      |
         |                          |               |
         |              .Réponse    | S-Nom,        |
         |                          | S-Indice      |
         |__________________________|_______________|

Tableau 2 : Primitives de temporisateurs

Le paramètre Temps indique la durée du temporisateur spécifié. Une étiquette d'identification est associée à un temporisateur au moyen du paramètre Nom. Le paramètre Indice spécifie une valeur pour distinguer les temporisateurs du même nom. Le nom et l'indice pris ensemble constituent une référence univoque au temporisateur.

Les temporisateurs utilisé en association avec une fonction de protocole spécifique sont définis avec cette fonction.

Note :	La présent norme internationale ne définie pas de valeurs spécifiques pour les temporisateurs. Toutes les indications décrites dans la présente norme sont non obligatoires. Les valeurs de temporisateur devraient être choisies de telle sorte que la qualité de service demandée puisse être fournie, étant données les caractéristiques choisies pour le service sous-jacent.

6.6	Types de sous-réseau

Afin d'évaluer l'applicabilité de ce protocole dans des configurations particulières des systèmes d'extrémité, des systèmes intermédiaires et des sous-réseaux, trois types génériques de sous-réseau sont identifiés. Ce sont :

1.	le sous-réseau point à point,
2.	le sous-réseau de diffusion,
3.	le sous-réseau de topologie générale.

Ces types de sous-réseau sont exposés dans les paragraphes suivants.

6.6.1	Sous-réseaux en point à point
Un sous-réseau en point à point prend en charge exactement deux systèmes. Les deux systèmes peuvent être deux systèmes d'extrémité, ou un système d'extrémité et un seul système intermédiaire. Un seule liaison de données en point à point connectant deux entités réseau est un exemple de sous-réseau en point à point.

Informations de configuration sur un sous-réseau en point à point. Sur un sous-réseau en point à point, les informations de configuration de ce protocole informent les entités réseau communicantes de ce qui suit :

1.	Si la topologie consiste seulement en deux systèmes d'extrémité, ou
2.	Si un des deux systèmes est un système intermédiaire.

Note :	Sur un sous-réseau en point à point, si les deux systèmes sont des systèmes intermédiaires, le présent protocole est inapplicable à la situation, car un protocole IS/IS devrait être plutôt employé. Cependant, il n'y a aucune raison pour que les informations de configuration ne puissent être employées dans un environnement IS/-IS pour s'assurer de la topologie et initialiser le fonctionnement d'un protocole IS/IS.

Le système intermédiaire est informé de la ou des adresses NSAP prises en charge par l'entité réseau dans le système d'extrémité. Cela permet que les informations d'accessibilité et les métriques d'acheminement concernant ces NSAP soient disséminées aux autres systèmes intermédiaires pour les besoins du calcul des chemins de et vers ce système d'extrémité.

Informations de redirection de chemin sur un sous-réseau en point à point. Les informations de redirection de chemin ne sont pas employées sur les sous-réseaux en point à point parce qu'il n'y a jamais de chemin de remplacement.

6.6.2	Sous-réseaux de diffusion
Un sous-réseau de diffusion prend en charge un nombre arbitraire de systèmes d'extrémité et de systèmes intermédiaires, et est de plus capable de transmettre une seule SNPDU à tous ou à un sous-ensemble de ces systèmes en réponse à une seule Demande SN_UNITDATA..Un exemple de sous-réseau de diffusion est un LAN (réseau de zone locale) conforme au fonctionnement du type 1 de la norme DIS8802/2.

Informations de configuration sur un sous réseau de diffusion. Sur un sous-réseau de diffusion, les informations de configuration de ce protocole sont employées pour informer les entités réseau communicantes de ce qui suit :

1.	Les systèmes d'extrémité sont informés de l'accessibilité, du titre d'entité réseau, et de la ou des adresses SNPA de chaque système intermédiaire actif sur le sous-réseau.

2.	Les systèmes intermédiaires sont informés des adresses NSAP prises en charge par chaque système d'extrémité et l'adresse de sous-réseau de l'ES. Une fois que le système intermédiaire a obtenu ces informations, les informations d'accessibilité et de métrique d'acheminement concernant ces NSAP peuvent être disséminées aux autres IS pour les besoins du calcul des chemins de/vers chaque ES du sous-réseau.

3.	En l'absence de système intermédiaire disponible, les systèmes d'extrémité peuvent interroger un sous-réseau de diffusion pour découvrir si un NSAP particulier est accessible sur le sous-réseau, et s'il en est ainsi, quelle adresse de SNPA utiliser pour atteindre ce NSAP.

Informations de redirection de chemin sur les sous-réseaux de diffusion. Les informations de redirection de chemin peuvent être employées sur les sous-réseaux de diffusion pour permettre aux systèmes intermédiaires d'informer les systèmes d'extrémité des chemins supérieurs vers un NSAP de destination. Le chemin supérieur peut être un autre IS sur le même sous-réseau que l'ES, ou il peut être l'ES de destination lui-même, si il est directement accessible sur le même sous-réseau que l'ES de source.

6.6.3	Sous réseaux de topologie générale
Un sous-réseau de topologie générale prend en charge un nombre arbitraire de systèmes d'extrémité et de systèmes intermédiaires, mais ne prend pas en charge de facilité de transmission sans connexion multi-destination convenable comme le fait un sous-réseau de diffusion. Un exemple de sous-réseau de topologie générale est celui d'un sous-réseau employant X.25 ou ISO 8208.

Note :	La caractéristique distinctive cruciale entre le sous-réseau de diffusion et le sous-réseau de topologie générale est le "coût" d'une transmission multilatérale sur un sous-ensemble potentiellement large des systèmes du sous-réseau. Sur un sous-réseau de topologie générale, le coût est supposé être proche du coût de l'envoi d'une PDU individuelle à chaque SNPA du sous-réseau. À l'inverse, sur un sous-réseau de diffusion, le coût est supposé être proche du coût d'envoi d'une seule PDU à un SNPA sur le sous-réseau. Des situations intermédiaires entre ces extrêmes sont bien sûr possibles. Dans de tels cas; il serait possible de traiter le sous-réseau soit dans la catégorie diffusion, soit dans la catégorie topologie générale.

Informations de configuration sur un sous-réseau de topologie générale. Sur un sous-réseau de topologie générale, les informations de configuration ne sont généralement pas employées parce que ce protocole peut être très coûteux en utilisation des ressources de sous-réseau (et leur facturation).

Informations de redirection de chemin sur un sous-réseau de topologie générale. Les informations de redirection de chemin  peuvent être employées sur les sous-réseaux de topologie générale pour permettre aux systèmes intermédiaires d'informer les systèmes d'extrémité de chemins supérieurs vers un NSAP de destination. Le chemin supérieur peut être un autre IS sur le même sous-réseau que l'ES, ou il peut être l'ES de destination lui-même, si il est directement accessible sur le même sous-réseau que l'ES de source.

7	Fonctions du protocole

Cette section décrit les fonctions effectuées au titre du protocole. Chaque mise en œuvre n'est pas obligée d'effectuer toutes les fonctions. Le paragraphe 7.12 spécifie les fonctions qui peuvent être omises et le comportement correct lorsque les fonctions requises ne sont pas mises en œuvre.

7.1	Temporisateurs du protocole

Beaucoup des fonctions du protocole sont fondées sur l'utilisation de temporisateurs. Cela signifie qu'elles sont exécutées à l'arrivée à expiration d'un temporisateur plutôt qu'à réception d'une PDU ou que sur invocation d'une primitive de service. Le deux types majeurs de temporisateur employés par le protocole sont le temporisateur de configuration (CT, Configuration Timer) et le temporisateur de garde (HT, Holding Timer).

7.1.1	Temporisateur de configuration
Le temporisateur de configuration est un temporisateur local (c'est-à-dire, entretenu indépendamment par chaque système) qui effectue la fonction de rapport de configuration (voir le paragraphe 7.2). Le temporisateur détermine à quelle fréquence un système fait rapport de sa disponibilité aux autres systèmes sur le même sous-réseau. Plus le temporisateur de configuration est bref, plus rapidement les autres systèmes du sous-réseau seront avertis de ce que le système rapporteur devient disponible ou indisponible. La responsivité accrue doit être mise en balance avec l'augmentation d'utilisation des ressources dans le sous-réseau et les systèmes qui reçoivent.

7.1.2	Temporisateur de garde
Le temporisateur de garde s'applique aussi bien aux informations de configuration qu'aux informations de redirection de chemin . La valeur du temporisateur de garde est réglée par la source des informations et est transmise dans la PDU appropriée. Le receveur des informations n'est pas supposé conserver les information plus longtemps que le temporisateur de garde. Les vieilles informations de configuration ou de redirection de chemin doivent être éliminées après l'expiration du temporisateur de garde pour assurer le fonctionnement correct du protocole.

On trouvera un exposé complémentaire des raisons de ces temporisateurs et des lignes directrices pour leur utilisation à l'Annexe 10.

7.2	Fonction de rapport de configuration

La fonction de rapport de configuration est utilisée par les systèmes d'extrémité et les systèmes intermédiaires pour s'informer réciproquement de leur accessibilité et des adresses de sous-réseau en cours. Cette fonction est invoquée chaque fois que le temporisateur de configuration (CT) local arrive à expiration dans un ES ou IS. Il est aussi invoqué à réception d'une PDU d'interrogation de configuration provenant d'un autre système d'extrémité.

7.2.1	Rapport de configuration par les systèmes d'extrémité
Un système d'extrémité construit et transmet une PDU ESH (ESH pour "Hello de système d'extrémité") pour chaque NSAP qu'il dessert, et produit une Demande SN_UNITDATA. avec la PDU ESH comme SNSDU sur chaque sous-réseau auquel il est rattaché.

Note :	La nécessité de transmettre une PDU ESH séparée pour chaque NSAP desservi par l'entité réseau provient de l'absence de relation formalisée entre les titres d'entité réseau et les adresses NSAP. Si cette relation pouvait être contrainte pour exiger que toutes les adresses NSAP soient allouées comme sous-domaines d'extrémité d'un domaine représenté par le titre d'entité réseau de l'entité réseau locale, une seule PDU ESH pourrait alors être transmise qui contiendrait le titre d'entité réseau des ES. Le titre d'entité réseau impliquerait alors quels NSAP peuvent être présents à ce système d'extrémité.

Le champ Temporisateur de garde (HT, Holding Timer) est réglé approximativement à deux fois le paramètre Temporisateur de configuration (CT) des ES. Cette variable est réglée à une valeur assez grande pour que même si chaque autre PDU ESH est éliminée (à cause d'un manque de ressources), ou autrement perdue dans le sous-réseau, les informations de configuration seront quand même conservées. La valeur doit être réglée assez petite pour que les systèmes intermédiaires puissent répondre à temps aux systèmes d'extrémité qui deviennent disponibles ou indisponibles.

Le paramètre SN_Destination_Address est réglé à l'adresse de groupe qui indique "Toutes les entités réseau de système intermédiaire". Cela assure qu'une seule transmission sur un sous-réseau de diffusion va atteindre tous les systèmes intermédiaires actifs.

Note :	La valeur réelle de SN_Destination_Address utilisée pour signifier "Toutes les entités réseau de système intermédiaire" dépend du sous-réseau et va très vraisemblablement varier d'un sous-réseau à l'autre. Il serait bien sûr souhaitable que sur les types de sous-réseau largement utilisés (tels que ceux qui se fondent sur le DIS 8802) cette valeur et la valeur de l'adresse de groupe "Toutes les entités réseau de système intermédiaire" soient normalisées.

7.2.2	Rapport de configuration par les systèmes intermédiaires
Un système intermédiaire construit une seule PDU ISH (ISH pour "Hello de système intermédiaire") contenant le titre d'entité réseau des IS et produit une Demande SN_UNITDATA. avec la PDU ISH PDU comme SNSDU sur chaque sous-réseau auquel il est rattaché.

Le champ Temporisateur de garde (HT) est réglé à approximativement deux fois le paramètre Temporisateur de configuration (CT) du système intermédiaire. Cette variable est réglée à une valeur assez grande pour que même si toutes les autres PDU ISH sont éliminées (à cause du manque de ressources), ou autrement perdues dans le sous-réseau, les informations de configuration seront quand même conservées. La valeur doit être réglée assez petite pour que les systèmes d'extrémité cessent rapidement d'utiliser les IS qui sont défaillants, empêchant ainsi les "trous noirs" dans le réseau.

Le paramètre SN_Destination_Address est réglé à l'adresse de groupe qui indique "Toutes les entités réseau de système d'extrémité". Cela assure qu'une seule transmission sur un sous-réseau de diffusion va atteindre tous les systèmes d'extrémité actifs.

7.3	Fonction d'enregistrement de configuration

La fonction Configuration d'enregistrement reçoit les PDU ESH ou ISH, extrait les informations de configuration, et ajoute ou remplace les informations de configuration correspondantes dans la base de données d'informations d'acheminement de l'entité réseau locale. Si un espace insuffisant est disponible pour mémoriser les nouvelles informations de configuration, la PDU est éliminée. Aucun rapport d'erreur n'est généré.

Note :	Le protocole est décrit de telle sorte que les systèmes d'extrémité reçoivent et enregistrent seulement les PDU ISH et que les systèmes intermédiaires reçoivent et traitent seulement les PDU ESH. Si un ES le désire cependant, il peut décider de traiter aussi les PDU ESH (sur un réseau de diffusion, ceci est fait facilement en activant l'adresse de groupe appropriée). Il y a un potentiel d'amélioration des performances à gagner en faisant cela, aux dépens d'un supplément de mémoire, et éventuellement de cycles de traitement supplémentaires dans le système d'extrémité. L'ES, en enregistrant les informations de configuration des autres ES, peut être capable d'acheminer directement les NPDU aux ES sur le sous-réseau local sans être d'abord redirigés par un système intermédiaire.

	De même, les systèmes intermédiaires peuvent choisir de recevoir les PDU ISH d'autres IS, permettant d'utiliser ce protocole comme la portion d'initialisation et de maintenance de topologie d'un protocole complet d'acheminement IS/IS. Ces deux possibilités feront l'objet d'études ultérieures.

7.4	Fonction de purge d'ancienne configuration

La fonction de purge de l'ancienne configuration est exécutée pour retirer les entrées de configuration de la base de données d'informations d'acheminement dont le temporisateur de garde est arrivé à expiration. Lorsque le temporisateur de garde arrive à expiration pour un ES ou un IS, cette fonction retire l'entrée correspondante de la base de données d'informations d'acheminement de l'entité réseau locale.

7.5	Fonction d'interrogation de configuration

La fonction d'interrogation de configuration est effectuée dans les circonstances suivantes :

1.	Le système d'extrémité est rattaché à un sous-réseau de diffusion,

2.	Il n'y a pas de système intermédiaire actuellement joignable sur le sous-réseau (c'est-à-dire. aucune PDU ISH n'a été reçue depuis que les dernières informations ont été purgées par la fonction de purge d'ancienne configuration),

3.	La fonction de PDU d'acheminement de la couche réseau a besoin d'obtenir l'adresse de SNPA à laquelle transmettre une PDU destinée à un certain NSAP,

4.	L'adresse de SNPA ne peut être obtenue ni par une transformation locale ni par une recherche de tableau local.

Note :	En dépit des apparences, ceci est en fait un cas assez courant, car il est vraisemblable qu'il y aura de nombreux réseaux de zone locale isolés sans systèmes intermédiaires sur lesquels s'appuyer pour obtenir les informations d'acheminement (par exemple, via la fonction de redirection de demande du présent protocole). De plus, si le ou les systèmes intermédiaires sont temporairement indisponibles, sans cette capacité, les communications sur le sous-réseau local vont souffrir si des tableaux entrés à la main ne sont présents dans chaque système d'extrémité ou si tous les NSAP du sous-réseau n'ont l'adresse SNPA du sous-réseau incorporée.

Le système d'extrémité, lorsque il a besoin d'acheminer une NPDU à un NSAP de destination dont le SNPA est inconnu, produit une Demande SN_UNITDATA. avec la NPDU comme SN_Userdata. Le paramètre SN_Destination_Address est réglé à l'adresse de groupe qui indique "Toutes les entités réseau de système d'extrémité".

Ensuite une PDU ESH peut être reçue qui contient l'adresse NSAP avec l'adresse de  SNPA correspondante (voir au paragraphe 7.6). Dans un tel cas, le système d'extrémité exécute la fonction d'enregistrement de configuration pour le NSAP, et sera donc capable d'acheminer les PDU suivantes à cette destination en utilisant le SNPA spécifié. Si aucune PDU ESH n'est reçue, le système d'extrémité peut déclarer le NSAP de destination injoignable. La durée de l'attente d'une réponse avant d'indiquer une défaillance ou la possibilité de répéter le processus un certain nombre de fois avant de retourner une défaillance est une question locale qui n'est pas spécifiée dans la présente norme.

7.6	Fonction de réponse de configuration

La fonction de réponse de configuration est effectuée lorsque un système d'extrémité rattaché à un sous-réseau de diffusion reçoit une NPDU adressée à un de ses NSAP, avec SN_Destination_Address provenant de SN_UNITDATA.Indication réglé à l'adresse de groupe "Toutes les entités réseau de système d'extrémité". Cela survient lorsque un autre ES a effectué la fonction d'interrogation de configuration décrite au paragraphe 7.5.

Le système d'extrémité construit une PDU ESH identique en contenu à la PDU ESH construite par la fonction de rapport de configuration (voir au paragraphe 7.2.1) pour le NSAP auquel la NPDU reçue était adressée. Il transmet alors la PDU ESH à la source de la NPDU d'origine en produisant une Demande SN_UNITDATA. avec SN_Destination_Address réglée à la valeur de la SN_Source_Address reçue dans l'Indication SN_UNITDATA. avec la NPDU d'origine.

7.7	Fonction de demande de redirection

La fonction de demande de redirection n'est présente que dans les systèmes intermédiaires et est étroitement couplée aux fonctions d'acheminement et de relais des systèmes intermédiaires. La fonction de demande de redirection est couplée avec la "Fonction de PDU d'acheminement" décrite au paragraphe 6.5 de la norme ISO 8473. La fonction de demande de redirection est effectuée après que la fonction de PDU d'acheminement a calculé le prochain bond du chemin de la PDU de données.

Lorsque une NPDU est à transmettre par un système intermédiaire, la fonction de demande de redirection examine d'abord la SN_Source_Address associée à l'Indication SN_UNITDATA. qui a reçu la SNSDU (qui contient cette NPDU). Si la SN_Source_Address ne provient pas d'un système d'extrémité sur le sous-réseau local (ce qui est déterminé en examinant les informations de configuration obtenues par la fonction d'enregistrement de configuration), cette fonction ne fait alors aucune autre traitement sur cette NPDU.

Si la NPDU a été reçue directement d'un ES, le résultat de la fonction d'acheminement et de relais de l'IS pour cette NPDU est examiné. Ce résultat va contenir, entre autres choses, les éléments d'information suivants :

1.	un identifiant local pou le sous-réseau sur lequel transmettre la NPDU, plus soit

2.	le titre d'entité réseau et l'adresse de sous-réseau de l'IS auquel transmettre la NPDU, soit

3.	l'adresse de sous-réseau du système d'extrémité de destination.

La fonction de demande de redirection doit maintenant déterminer si l'ES de source pourrait avoir envoyé la NPDU directement à l'entité réseau à laquelle le système intermédiaire est sur le point de transmettre la PDU. Si une des conditions suivantes est réalisée, l'ES de source devrait être informé du "meilleur" chemin (en envoyant une PDU RD à l'ES d'origine) :

1.	Le prochain bond est au système de destination, et la destination est directement joignable (à la BSNPA) sur le sous-réseau de l'ES de source, ou

2.	Le prochain bond est à un système intermédiaire qui est connecté au même sous-réseau que l'ES.

Si le meilleur chemin existe, l'IS achève d'abord le traitement normal de la NPDU reçue et la transmet. Il construit ensuite une PDU Redirect (PDU RD) contenant l'adresse de destination de la NPDU d'origine, l'adresse de sous-réseau du meilleur prochain bond (BSNPA), le titre d'entité réseau de l'IS sur lequel l'ES est redirigé (sauf si le redirect est sur l'ES de destination), un temps de garde (HT, Holding Time), un maintenance de qualité de service, une priorité, et les options de sécurité qui étaient présentes dans la NPDU de données (qui sont simplement copiées de la PDU de données). Le HT est réglé à la valeur du temporisateur Redirect (RT) local. Voir à l'Annexe A un exposé sur la façon de choisir la valeur de RT. Si les ressources sont insuffisantes pour à la fois transmettre la NPDU originale et générer et envoyer une PDU RD, la NPDU originale doit avoir la préférence. Le système intermédiaire (en supposant qu'il a des ressources suffisantes) envoie alors la PDU RD au système d'extrémité de source en utilisant la SN_Source_Address de la NPDU reçue comme SN_Destination_Address pour la Demande SN_UNITDATA.

7.8	Fonction d'enregistrement de redirection

La fonction d'enregistrement de redirection n'est présente que dans les systèmes d'extrémité. Cette fonction est invoquée chaque fois qu'une PDU RD est reçue. Elle extrait les informations de redirection et ajoute ou remplace les informations de redirection correspondantes dans la base de données d'information d'acheminement de l'entité réseau locale. L'information essentielle est la transposition de redirection d'une adresse de destination à une adresse de sous-réseau, avec les options de priorité, de sécurité et de maintenance de qualité de service ainsi que le temps de garde pendant laquelle cette transposition sera considérée comme valide. Si le Redirect était sur un autre système intermédiaire, le titre d'entité réseau de l'IS est aussi enregistré.

Note :	Si la mémoire est insuffisante pour enregistrer les nouvelles informations de redirection , la PDU RD peut être éliminée en toute sécurité car le système intermédiaire d'origine va de toutes façons continuer à transmettre des PDU au nom de cette entité réseau.

7.9	Fonction de rafraîchissement de redirection

La fonction de rafraîchissement de redirection n'est présente que dans les systèmes d'extrémité. Cette fonction est invoquée chaque fois qu'une NPDU est reçue par un ES de destination. Elle est étroitement couplée à la fonction qui traite les NPDU reçus à une entité réseau de destination. C'est la fonction de "décomposition de PDU" dans la norme ISO 8473. L'objet de cette fonction est d'accroître la longévité d'une redirection sans permettre à un chemin incorrect de persister indéfiniment. Les options adresse de source (SA, Source Address), priorité, sécurité et qualité de service (QS) sont extraites et comparées à tous les paramètres d'adresse de destination et QS qui sont conservés dans la base de données d'information d'acheminement (comme les informations qui auraient été mémorisées par la fonction d'enregistrement de redirection). Si une entrée correspondante est trouvée, le précédent bond de la PDU est obtenu du paramètre SN_Source_Address de la primitive Indication SN_Unitdata. par laquelle elle a été reçue. Si cette adresse correspond à l'adresse de prochain bond mémorisée avec les informations de redirection, le temps de garde restante pour la redirection est remise à la valeur originale du temporisateur de garde qui a été obtenue de la PDU RD.

Note :	L'objet de cette fonction est d'éviter de faire arriver à expiration des entrées de redirection lorsque l'entité réseau reçoit du trafic en retour de la destination via le même chemin que celui sur lequel elle envoie actuellement du trafic. Ceci est particulièrement utile lorsque le système de destination est sur le même sous-réseau que la source, car après une redirection aucun IS n'a besoin d'être impliqué dans le trafic d'ES à ES.

	Cette fonction doit opérer cependant de façon très prudente, pour empêcher la formation de trous noirs. Le temps de garde restant ne devrait être rafraîchi que dans les exactes conditions spécifiées ci-dessus. Pour un exposé sur les question qui entourent le rafraîchissement des informations de redirection, voir à l'Annexe 10.

7.10	Fonction de purge d'ancienne redirection

La fonction de purge d'ancienne redirection est exécutée pou retirer les entrées de configuration dans la base de données d'informations d'acheminement dont le temporisateur de garde est arrivé à expiration. Lorsque le temporisateur de garde arrive à expiration pour un ES ou IS, cette fonction retire l'entrée correspondante de la base de données d'informations d'acheminement de l'entité réseau locale.

7.11	Détection d'erreur d'en-tête de PDU

La fonction de détection d'erreur d'en-tête de PDU protège contre les défaillances d'entité réseau de système intermédiaire ou de système d'extrémité dues au traitement d'informations erronées dans l'en-tête de la PDU. La fonction est réalisée par une somme de contrôle calculée sur l'en-tête entier de la PDU. La somme de contrôle est vérifiée à chaque point de traitement de la PDU. Si le calcul de la somme de contrôle échoue, la PDU doit être éliminée.

L'utilisation de la fonction de détection d'erreur d'en-tête de PDU est facultatif et est choisi par l'entité réseau d'origine. Si la fonction n'est pas utilisée, le champ somme de contrôle de l'en-tête de la PDU est mis à zéro.

Si la fonction est retenue par l'entité réseau d'origine, la valeur du champ Somme de contrôle cause la satisfaction des formules suivantes :

(Somme de i=1 à L de a(i)) (mod. 255) = 0

(Somme de i=1 à L de  (L - i + 1) * a(i)) (mod. 255) = 0

où L = nombre d'octets de l'en-tête de PDU, et a(i) = valeur de l'octet à la position i. Le premier octet dans l'en-tête de PDU est considéré comme occupant la position i = 0.

Lorsque cette fonction est utilisée, aucun octet du champ somme de contrôle ne peut être réglé à zéro.

7.12	Classification des fonctions

Les mises en œuvre n'ont pas à prendre en charge toutes les fonctions décrites à la Section 7. Les fonctions sont divisées en quatre catégories :

Type A :	Ces fonctions doivent être prise en charge dans tous les cas.

Type B :	Ces fonctions doivent être prises en charge par les systèmes qui mettent en œuvre les informations de configuration.

Type C :	Ces fonctions doivent être prises en charge par les systèmes qui mettent en œuvre les informations de redirection.

Type D :	Ces fonctions sont facultatives.

Si une PDU reçue invoque une fonction facultative qui n'est pas mise en œuvre, cette PDU sera éliminée.

Le Tableau 3 montre comment les fonctions sont réparties dans ces quatre catégories, et à quel type de système (ES, IS, ou les deux) elles s'appliquent.

Fonction	Catégorie	Type de système	
Rapport de configuration	B	ES,IS	
Enregistrement de configuration	B	ES,IS	
Réponse de configuration 	A	ES	
Purge de l'ancienne configuration	B	ES,IS	
Demande de redirection	C	IS	
Interrogation de configuration	B	ES	
Enregistrement de redirection	C	ES	
Rafraîchissement de redirection	D	ES	
Purge de l'ancienne redirection	C	ES	
Détection d'erreur d'en-tête de PDU	A	ES,IS	

Table 3 : Catégories de fonctions de protocole

8	Structure et codage des PDU

Note :	Le codage des PDU pour ce protocole est compatible avec celui utilisé dans la norme ISO 8473.

Note temporaire :	 La méthode employée pour décrire le codage des PDU est provisoire. Les organisations membres sont invitées à commenter si une autre méthode (comme l'ASN.1 avec une syntaxe concrète appropriée) serait préférable.

8.1	Structure

Toutes les unités de données de protocole doivent contenir un nombre entier d'octets. Les octets dans une PDU sont numérotés à partir de un (1) et en ordre croissant suivant qu'ils sont mis dans une SNSDU. Les bits d'un octet sont numéroté de un (1) à huit (8), et le bit un (1) est le bit de moindre poids. Lorsque des octets consécutifs sont utilisés pour représenter un nombre binaire, le plus faible numéro d'octet a la valeur de plus fort poids.

Tout sous-réseau qui prend en charge le présent protocole est obligé de déclarer dans sa spécification la façon dont les octets sont transférés, en utilisant les termes "bit de poids fort" et "bit de moindre poids". Les PDU du présent protocole sont définis en utilisant les termes "bit de poids fort" et "bit de moindre poids".

Note :	Lorsque le codage d'une PDU est représenté dans cette section en utilisant un diagramme, on utilise la représentation suivante :
	a) les octets sont indiqués avec l'octet de plus faible numéro à gauche, les octets de numéro supérieur étant plus à droite ;
	b) au sein d'un octet, les bits sont indiqués avec le bit huit (8) à gauche et le bit un (1) à droite.

Les PDU doivent contenir, dans l'ordre suivant :
1.	la partie fixe ;
2.	la partie d'adresse réseau ;
3.	la partie adresse de sous-réseau, si elle est présente ;
4.	la partie options, si elle est présente.

8.2	Partie fixe
8.2.1	Généralités
La partie fixe contient les paramètres qui surviennent fréquemment, y compris les code de type (ESH, ISH, ou RD) de l'unité de données de protocole. La longueur et la structure de la partie fixe sont définies par le code de PDU.

La partie fixe a le format suivant :

                                               Octet
      ________________________________________
      |Identifiant protocole de couche réseau|    1
      |______________________________________|
      |           Indicateur de longueur     |    2
      |______________________________________|
      | Extension d'ID de version/protocole  |    3
      |______________________________________|
      |        réservé (doit être à zéro)    |    4
      |______________________________________|
      | 0 |0 |0 |           Type             |    5
      |___|__|__|____________________________|
      |           Temps de garde             |   6, 7
      |______________________________________|
      |        Somme de contrôle             |   8, 9
      |______________________________________|

Figure 1 : En-tête de PDU – Partie fixe

8.2.2	Identifiant de protocole de couche réseau
La valeur de ce champ doit être 1000 0010.

Note temporaire :	La valeur 1000 0010 est provisoire, en attendant la résolution de la question du NLPID au SC6.

Ce champ identifie ce protocole de couche réseau comme ISO SC6/N4053, protocole d'échange d'informations d'acheminement de système d'extrémité à système intermédiaire à utiliser en conjonction avec la norme ISO 8473.

8.2.3	Indicateur de longueur
La longueur est indiquée par un nombre binaire, avec une valeur maximum de 254 (1111 1110). La longueur indiquée est la longueur de la PDU entière (qui consiste entièrement en un en-tête, car ce protocole ne porte aucune données d'utilisateur) en octets, comme décrit au paragraphe 8.1. La valeur 255 (1111 1111) est réservée pour de possibles extensions futures.

8.2.4	Extension d'identifiant de version/protocole
La valeur de ce champ est 0000 0001 en binaire. Cela identifie une version standard de ISO xxxx, protocole d'échange d'informations d'acheminement de système d'extrémité à système intermédiaire à utiliser en conjonction avec la norme ISO 8473.

8.2.5	Code de type
Le champ code de type identifie le type d'unités de données de protocole. Les valeurs permises sont données au tableau 4.

   _____________________________________________________
   |            | Bits               5   4   3   2   1 |
   |____________|______________________________________|
   |____________|______________________________________|
   |PDU ESH     |                    0   0   0   1   0 |
   |____________|______________________________________|
   |PDU ISH     |                    0   0   1   0   0 |
   |____________|______________________________________|
   |PDU RD      |                    0   0   1   1   0 |
   |____________|______________________________________|

Tableau 4 : Types valides de PDU

Toutes les autres valeurs de type de PDU sont réservées.

8.2.6	Temps de garde
Le champ Temps de garde spécifie la durée pendant laquelle l'entité réseau receveuse devrait conserver les informations de configuration/acheminement contenues dans cette PDU. L'entité réseau receveuse devrait éliminer toute information obtenue de cette PDU à partir de son état interne lorsque le temps de garde est arrivé à expiration. Le champ Temps de garde est codé comme un nombre entier de micro quinzaines.

8.2.7	Somme de contrôle de PDU
La somme de contrôle est calculée sur l'en-tête de PDU entier. Une valeur de somme de contrôle de zéro est réservée pour indiquer que la somme de contrôle est à ignorer. Le traitement de la fonction de détection d'erreur d'en-tête de PDU (paragraphe 7.11) assure que la valeur zéro ne représente pas une somme de contrôle valide. Une valeur différente de zéro indique que la somme de contrôle doit être traitée. Si le calcul de la somme de contrôle échoue, la PDU doit être éliminée.

8.3	Partie d'adresse réseau
8.3.1	Généralités
Les paramètres d'adresse se distinguent par leur localisation. Les différents types de PDU portent cependant des paramètres d'adresse différents. La PDU ESH porte une adresse NSAP de source (SA) ; la PDU ISH porte un titre d'entité réseau (NET) de système intermédiaire ; et la PDU RD porte une adresse NSAP de destination (DA), et éventuellement un titre d'entité réseau (NET).

8.3.2	Codage des NPAI
Les informations d'adresse de protocole réseau (NPAI, Network Protocol Address Information) comportent l'adresse de destination et l'adresse de source qui sont des adresses de point d'accès de service réseau telles que définies dans ISO 8348/AD2, Addendum à la définition de service réseau couvrant l'adressage de couche réseau. Le paramètre d'adresse de titre d'entité réseau est défini au paragraphe 4.5. L'adresse de destination, l'adresse de source, et le titre d'entité réseau sont codés comme NPAI en utilisant la syntaxe binaire définie au paragraphe 8.3.1 de ISO 8348/AD2.

Les informations d'adresse sont de longueur variable. Chaque paramètre d'adresse est codé comme suit :

         _______________________________________________
         | Octet  | Indicateur de longueur de paramètre|
         |   n    | d'adresse (par exemple 'm')        |
         |________|____________________________________|
         | Octets |                                    |
         | n + 1  |     Valeur de paramètre            |
         |  à     |        d'adresse                   |
         | n + m  |                                    |
         |________|____________________________________|

Figure 2 : Paramètres d'adresse

8.3.3	Paramètres d'adresse de source pour PDU ESH
L'adresse de source est l'adresse NSAP d'un NSAP desservi par l'entité réseau qui envoie la PDU ESH. Elle est codée dans la PDU ESH comme suit :

                                                   Octet
         ________________________________________
         |   Indicateur de longueur d'adresse   |   10
         |    de source (SAL)                   |
         |______________________________________|
         |                                      |   11
         :           Adresse de source (SA)     :
         |                                      |  m - 1
         |______________________________________|

Figure 3 : PDU ESH – Partie adresse réseau

8.3.4	Paramètre Titre d'entité réseau pour PDU ISH
Le paramètre Titre d'entité réseau est le titre de l'entité réseau du système intermédiaire qui envoie la PDU ISH. Il est codé dans la PDU ISH comme suit :

                                                   Octet
   _______________________________________________
   |       Indicateur de longueur de titre       |  10
   |          d'entité réseau (NETL)             |
   |_____________________________________________|
   |                                             |  11
   :          Titre d'entité réseau  (NET)       :
   |                                             | m - 1
   |_____________________________________________|

Figure 4 : PDU ISH - Partie adresse réseau

8.3.5	Paramètre d'adresse de destination pour PDU RD
L'adresse de destination est l'adresse NSAP d'une destination associée à certaine NPDU transmise par le système intermédiaire qui envoi la PDU RD. Elle est codée dans la PDU RD comme suit :

                                                  Octet
    _____________________________________________
    |       Indicateur de longueur d'adresse    |  10
    |         de destination       (DAL)        |
    |___________________________________________|
    |                                           |  11
    :        Adresse de destination (DA)        :
    |                                           | m - 1
    |___________________________________________|

Figure 5 : PDU RD - Partie adresse réseau

8.4	Partie adresse de sous-réseau

La partie adresse de sous-réseau n'est présente que dans les PDU RD. Elle est utilisée pour indiquer l'adresse de sous-réseau d'une autre entité réseau sur le même sous-réseau que le système d'extrémité (et système intermédiaire) qui peut être un meilleur chemin pour la destination spécifiée dans la partie adresse réseau. Le paramètre Adresse de sous-réseau est codé de la même façon que les paramètres d'adresse réseau.

8.4.1	Paramètre d'adresse de sous-réseau pour la PDU RD
Le paramètre d'adresse de sous-réseau est codé dans la PDU RD comme suit :

                                                   Octet
    _______________________________________________
    |       Indicateur de longueur d'adresse      |   m
    |             de sous-réseau (BSNPAL)         |
    |_____________________________________________|
    |                                             | m + 1
    :     Adresse de sous-réseau (BSNPA)          :
    |                                             | n - 1
    |_____________________________________________|

Figure 6 : PDU ESH – partie adresse

8.5	Partie options
8.5.1	Généralités
La partie options est utilisée pour porter les paramètres facultatifs. La partie options de l'en-tête de PDU est illustrée ci-dessous :

                                                        Octet
    ___________________________________________________
    |                                                  |   p
    :                    Options                       :
    |                                                  |   q
    |__________________________________________________|

Figure 7 : Toutes PDU – partie options

Si la partie options est présente, elle peut contenir un ou plusieurs paramètres. Le nombre de paramètres qui peuvent être contenus dans la partie options est contrainte par la longueur de la partie options, qui est déterminée par la formule suivante :

Longueur d'en-tête de PDU - (longueur de partie fixe + longueur de partie adresse + longueur de partie segmentation),

et par la longueur des paramètres facultatifs individuels.

Les paramètres définis dans la partie facultative peuvent apparaître dans n'importe quel ordre. La duplication des options n'est pas permise. La réception d'une PDU avec une option dupliquée doit être traitée comme erreur de protocole.

Le codage des paramètres contenus dans la partie options de l'en-tête de la PDU est illustrée à la Figure 8.

          Octets
          _________________________________
          |     n      | Code de paramètre |
          |____________|___________________|
          |   n + 1    |Longueur de param. |
          |____________|___________________|
          |   n + 2    |                   |
          |     à      |Valeur de paramètre|
          | n + m + 1  |                   |
          |____________|___________________|

Figure 8 : Codage des paramètres d'option

Le champ Code de paramètre est codé en binaire et, sans extensions, fournit un maximum de 255 paramètres différents. Aucun code de paramètre n'utilise les bits 8 et 7 avec la valeur 00, de sorte que le nombre maximum réel de paramètres est inférieur. Un code de paramètre de 255 (1111 1111 en binaire) est réservé pour de possibles extensions  futures.

Le champ Longueur de paramètre indique la longueur, en octets, du champ de valeur du paramètre. La longueur est indiquée par un nombre binaire positif, m, avec une valeur théorique maximum de 254. La valeur maximum pratique de m est inférieure. Par exemple, dans le cas d'un seul paramètre contenu dans la partie options, deux octets sont nécessaires pour le code de paramètre et les indicateurs de longueur de paramètre. Et donc, la valeur de m est limitée à :

m = 252-(longueur de partie fixe + longueur de partie adresse + longueur de partie segmentation    )

Pour chaque paramètre successif, la valeur maximum de m décroît. Le champ de valeur du paramètre contient la valeur du paramètre identifié dans le champ Code de paramètre.

Les paramètres suivants sont permis dans la partie options.

8.5.2	Sécurité
Le paramètre Sécurité porte des informations sur la sécurité demandée dans la PDU Données qui a causé la génération de la PDU RD contenante. Ce paramètre a le même codage et la même sémantique que le paramètre Sécurité dans la norme ISO 8473.

Code de paramètre :	1100 0101
Longueur de paramètre :	variable
Valeur de paramètre :	Voir le paragraphe 7.5.3 de la norme ISO 8473

8.5.3	Maintenance de la qualité de service
Le paramètre Qualité de service porte des informations sur la qualité de service requise dans la PDU Données qui a causé la génération de la PDU RD contenante.

Ce paramètre a le même codage et la même sémantique que le paramètre Maintenance de QS dans la norme ISO 8473.

Code de paramètre :	1100 0011
Longueur de paramètre :	variable
Valeur de paramètre :	Voir le paragraphe 7.5.6 de la norme ISO 8473

8.5.4	Priorité
Le paramètre Priorité porte des informations sur la priorité requise dans la PDU Données qui a causé la génération de la PDU RD contenante.

Ce paramètre a le même codage et la même sémantique que le paramètre Priorité de la norme ISO 8473.

Code de paramètre :	1100 1101
Longueur de paramètre :	un octet
Valeur de paramètre :	Voir le paragraphe 7.5.7 de la norme ISO 8473

8.6	PDU de Hello de système d'extrémité (ESH)
8.6.1	Structure
La PDU ESH a le format suivant :

                                                    Octet
       _____________________________________________
       |  Identifiant de protocole de couche réseau |   1
       |____________________________________________|
       |           Indicateur de longueur           |   2
       |____________________________________________|
       |Extension d'identifiant de version/protocole|   3
       |____________________________________________|
       |           réservé (doit être zéro)         |   4
       |____________________________________________|
       |0 |0 |0 |                Type               |   5
       |__|__|__|___________________________________|
       |               Temps de garde               |  6,7
       |____________________________________________|
       |             Somme de contrôle              |  8,9
       |____________________________________________|
       | Indic. de longueur d'adresse source (SAL)  |  10
       |____________________________________________|
       |                                            |  11
       :           Adresse de source (SA)           :
       |                                            | m - 1
       |____________________________________________|
       |                                            |   m
       :                  Options                   :
       |                                            | p - 1
       |____________________________________________|

Figure 9 : Format de PDU ESH

8.7	PDU de Hello de système intermédiaire (ISH)
8.7.1	Structure
La PDU ISH a le format suivant :

                                                   Octet
   _______________________________________________
   |  Identifiant de protocole de couche réseau  |   1
   |_____________________________________________|
   |            Indicateur de longueur           |   2
   |_____________________________________________|
   |Extension d'identifiant de version/protocole |   3
   |_____________________________________________|
   |             réservé (doit être zéro)        |   4
   |_____________________________________________|
   |0 |0 |0 |                  Type              |   5
   |__|__|__|____________________________________|
   |                Temps de garde               |  6,7
   |_____________________________________________|
   |               Somme de contrôle             |  8,9
   |_____________________________________________|
   |Indic. longueur titre d'entité réseau (NETL) |  10
   |_____________________________________________|
   |                                             |  11
   :         Titre d'entité réseau (NET)        :
   |                                             | m - 1
   |_____________________________________________|
   |                                             |  m
   :                      Options                :
   |                                             | p - 1
   |_____________________________________________|

Figure 10 : Format de PDU ISH

8.8	PDU Redirect (RD)
8.8.1	Structure
La PDU RD a le format suivant :

                                                    Octet
   ______________________________________________
   |  Identifiant de protocole de couche réseau  |    1
   |_____________________________________________|
   |            Indicateur de longueur           |    2
   |_____________________________________________|
   |Extension d'identifiant de version/protocole |    3
   |_____________________________________________|
   |               réservé (doit être zéro)      |    4
   |_____________________________________________|
   |0 |0 |0 |                   Type             |    5
   |__|__|__|____________________________________|
   |                 Temps de garde              |   6,7
   |_____________________________________________|
   |                Somme de contrôle            |   8,9
   |_____________________________________________|
   | Indic. longueur adresse de destination (DAL)|   10
   |_____________________________________________|
   |                                             |   11
   :           Adresse de destination (DA)       :
   |                                             | m - 1
   |_____________________________________________|
   |Indic. longueur adresse de sous-rés. (BSNPAL)|   m
   |_____________________________________________|
   |                                             | m + 1
   :          Adresse de sous-réseau (DBSNPA)    :
   |                                             | n - 1
   |_____________________________________________|
   |Indic. longueur titre d'entité réseau (NETL) |   n
   |_____________________________________________|
   |                                             | n + 1
   :          Titre d'entité réseau (NET)        :
   |                                             | p - 1
   |_____________________________________________|
   |                                             |   p
   :                        Options              :
   |                                             | q - 1
   |_____________________________________________|

Figure 11 : Format de PDU RD lorsque le Redirect est sur un IS

                                                    Octet
   ______________________________________________
   |  Identifiant de protocole de couche réseau  |    1
   |_____________________________________________|
   |            Indicateur de longueur           |    2
   |_____________________________________________|
   |Extension d'identifiant de version/protocole |    3
   |_____________________________________________|
   |               réservé (doit être zéro)      |    4
   |_____________________________________________|
   |0 |0 |0 |                   Type             |    5
   |__|__|__|____________________________________|
   |                 Temps de garde              |   6,7
   |_____________________________________________|
   |                Somme de contrôle            |   8,9
   |_____________________________________________|
   | Indic. longueur adresse de destination (DAL)|   10
   |_____________________________________________|
   |                                             |   11
   :           Adresse de destination (DA)       :
   |                                             | m - 1
   |_____________________________________________|
   |Indic. longueur adresse de sous-rés. (BSNPAL)|   m
   |_____________________________________________|
   |                                             | m + 1
   :          Adresse de sous-réseau (DBSNPA)    :
   |                                             | n - 1
   |_____________________________________________|
   |                   NETL = 0                  |   n
   |_____________________________________________|
   |                                             | n + 1
   :                   Options                   :
   |                                             | p - 1
   |_____________________________________________|
   |              Qualité de service             | n + 1
   |_____________________________________________|

Figure 12 : Format de PDU RD lorsque le Redirect est sur un ES

9	Description formelle

{Peut-être au prochain passage...}

10	Conformité

Voir au paragraphe 6.2.

Annexe A	Prise en charge du matériel technique

A.1	Utilisation des temporisateurs

Le présent protocole fait une utilisation abondante des temporisateurs pour assurer la livraison en temps utile et la précision des informations disséminées en utilisant les fonctions de configuration et de redirection de chemin. La présente section expose les raisons de l'utilisation de ces temporisateurs et donne les fondements de leur fonctionnement.

Les systèmes qui utilisent ce protocole apprennent sur les autres systèmes exclusivement par la réception des PDU envoyées par ces systèmes. Dans un environnement sans connexion, un système doit périodiquement recevoir des informations mises à jour pour s'assurer que les informations qu'il a reçues précédemment sont encore correctes. Par exemple, si un système sur un sous-réseau devient indisponible (soit qu'il ait cessé de fonctionner, soit que son SNPA devienne inopérant) la seule façon par laquelle un autre système peut détecter ce fait est par l'absence de transmissions provenant de ce système. Si les informations étaient conservées en l'absence de la réception de nouvelles PDU, les informations de configuration et/ou d'acheminement deviendraient inévitablement incorrectes. Le temporisateur de garde spécifié par ce protocole garantit que les vieilles informations ne seront pas conservées indéfiniment.

Une façon utile de voir les informations de configuration et de redirection de chemin est une antémémoire entretenue par chaque système. L'antémémoire est périodiquement purgée pour s'assurer que seules des informations à jour sont mémorisées. À la différence de la plupart des antémémoires, cependant, la durée de rétention des informations n'est pas une question purement locale. Les informations sont plutôt détenues pendant une durée spécifiée par la source des informations. Quelques exemples vont nous aider à préciser ce fonctionnement.

A.1.1	Exemple de temporisateur de garde pour la redirection de chemin
Les informations de redirection de chemin  sont obtenues par un système d'extrémité par une fonction de demande de redirection (voir au paragraphe 7.7). Il est assez possible qu'un système intermédiaire puisse rediriger un système d'extrémité sur un autre IS qui est récemment devenu indisponible (cela peut arriver si l'algorithme d'acheminement IS/IS converge toujours suite à un changement de configuration). Si le temporisateur de garde n'était pas présent, ou avait été réglé sur une durée très longue par l'IS d'envoi, un système d'extrémité aurait été redirigé sur un trou noir d'où aucune de ses PDU de données n'aurait jamais émergé. La durée du temporisateur de garde su un Redirects spécifie, par nature, la durée pendant laquelle l'existence des tous noirs est permise.

D'un autre côté, le réglage très court du temporisateur de garde sur les redirections de chemin pour minimiser les effets des tous noirs a d'autres conséquences indésirables. D'abord, pour chaque PDU qui cause une redirection, une PDU supplémentaire doit être composée et transmise à côté de la PDU de données d'origine ; cela augmente la redondance. Ensuite, chaque fois qu'un temporisateur de garde de redirection "en fonction" arrive à expiration, le système d'extrémité redirigé va sel rabattre sur un plus mauvais chemin pour au moins une PDU.

A.1.2	Exemple de temporisateur de garde pour les informations de configuration
Un type de problème similaire peut survenir par rapport aux informations de configuration. Si le temporisateur de garde d'une PDU ISH (voir au paragraphe 7.2.2) est réglé à une durée très longue, et si le seul système intermédiaire (qui a envoyé ces informations de configuration) sur le sous-réseau devient indisponible, un trou noir de la taille du sous-réseau peut se former. Durant ce temps, les systèmes d'extrémité sur le sous-réseau peuvent n'être pas capables de communiquer les uns avec les autres parce qu'ils présument que fonctionne un système intermédiaire qui va transmettre leurs PDU de données aux ES de destination sur le sous-réseau local et retournera les PDU RD. Une fois le temporisateur de garde arrivé à expiration, les ES vont réaliser qu'aucun IS n'est disponible et leur seul recours sera d'envoyer leur trafic directement sur le sous-réseau local.

Étant donné les types de problèmes qui peuvent survenir, il est important que la responsabilité des informations incorrectes puisse être allouée sans ambiguïté à la source des informations. C'est pour cette raison que tous les temporisateurs de garde sont calculés par la source des informations de configuration ou de redirection de chemin et communiquées explicitement à chaque receveur dans la PDU appropriée.

A.2	Rafraîchissement et fin de temporisation des informations de redirection

Le protocole permet aux systèmes d'extrémité de rafraîchir les informations de redirection sans permettre que le temporisateur de garde n'arrive d'abord à expiration et d'être redirigées par un système intermédiaire pour la seconde fois (ou d'autres fois). De tels schémas sont prévalents dans les sous-réseaux sans connexion et sont souvent appelés "informations de chemin inverse", "antémémoire de bond précédent" ou quelque chose de similaire.

Rafraîchir les informations de redirection a un avantage évident sur les performances, mais peut être dangereux si ce n'est pas traité de façon très prudente. Pour qu'une redirection soit rafraîchie en toute sécurité, toutes les conditions suivantes doivent être réunies :

1.	L'adresse de source de la PDU reçue doit être exactement la même que l'adresse de destination spécifiée dans une PDU RD précédente (cela définit une "correspondance" sur les informations de redirection). Faire des hypothèses sur l'équivalence d'adresses abrégées, des adresses de groupe, ou des adresses "spéciales" similaires est dangereux car l'acheminement pour ces adresses ne peut pas être supposé identique.

2.	Le paramètre Qualité de service de la PDU reçue doit être exactement le même que le paramètre QS spécifié dans l' entrée de redirection correspondante (par l'adresse de destination). Ici encore, il n'est pas garanti que des PDU ayant des paramètres de QS différents seront acheminés de la même façon. Il est assez possible que le chemin redirigé soit même un trou noir pour certaines valeurs du paramètre de QS (le champ sécurité est un bon exemple).

3.	Le "bond précédent" de la PDU de  données reçue doit correspondre au "prochain bond" mémorisé dans les informations de redirection. Précisément, le SN_Source_Address de l'Indication SN_UNITDATA. qui a reçu la PDU doit correspondre exactement à la SN_Destination_Address spécifiée dans la redirection à utiliser pour envoyer du trafic via la primitive Demande SN_UNITDATA.. Cette comparaison assure que les redirections ne sont rafraîchies que lorsque le trafic inverse est reçu du même IS (ou ES de destination) lorsque le trafic transmis est envoyé à eux (ou à travers eux). Cette vérification assure que les redirections ne sont pas rafraîchies sur la seule base du trafic reçu de la destination. Il est assez possible que le trafic indique simplement que le chemin de transmission utilisé ne fonctionne pas !

Noter que ces conditions permettent toujours le rafraîchissement dans les cas les plus utiles et les plus courants où la destination est un autre ES sur le même sous-réseau que l'ES de source, ou ceux où la redirection est pour un IS qui passe du trafic de/vers la destination dans les deux directions (c'est-à-dire que le chemin est symétrique).

A.3	Considérations pour l'initialisation du système

Le présent protocole est conçu pour faire des échanges d'informations aussi libres que possible à partir d'entités dépendantes des deux types de systèmes. donc, il n'est pas possible qu'un système d'extrémité demande que tous les systèmes intermédiaires sur sous-réseau fassent rapport de leur configuration, pas plus qu'il n'est possible qu'un système intermédiaire demande que tous les systèmes d'extrémité sur un sous-réseau fassent rapport de leur configuration.

Dans certains environnements de fonctionnement, la contrainte peut être imposée que les ES, lorsqu'ils deviennent opérationnels, découvrent l'existence d'un IS aussi tôt que possible. La relation inverse tient aussi si il est nécessaire qu'un IS découvre l'existence des systèmes d'extrémité aussi tôt que possible. Dans les deux cas, la disponibilité de ces informations est normalement déterminée par le temporisateur de configuration du système pour lequel la connaissance est désirée. IL y a donc un compromis à trouver entre la redondance associée à la réalisation des fonctions de Rapport et d'enregistrement de configuration et la disponibilité en temps utile des informations de configuration. Diminuer le temporisateur de configuration augment la disponibilité aux dépens d'un accroissement de la redondance.

La solution sui vante est recommandée pour régler la contrainte décrite ci-dessus. Lorsque la fonction Enregistrement de configuration est invoquée sur l'un ou l'autre système d'extrémité ou système intermédiaire, la fonction déterminera si les informations de configuration reçues était inconnues avant. Si c'est le cas, la fonction Rapport de configuration peut alors être invoquée avant l'expiration du temporisateur de configuration du système. La PDU Hello générée par la fonction Rapport de configuration n'est alors envoyée qu'à l'entité réseau dont la configuration était inconnue. Et donc, lorsque un ES ou IS devient opérationnel, il  fait immédiatement rapports de sa configuration. Aussitôt que les systèmes de l'autre type découvrent la nouvelle entité de réseau, elles vont faire connaître leur propre configuration à cette entité.

La redondance additionnelle encourue par cette solution est minimale. Aussi, comme la découverte de nouvelles configurations est faite à temps par cette approche, la période du temporisateur de configuration peut être augmentée afin de diminuer la redondance des fonctions de configuration, pourvu que d'autres facteurs non exposés ici soient pris en compte pour cette durée plus longue. Un avertissement est que la première PDU Hello générée par un système peut être perdue durant la transmission. Pour résoudre ce problème une ou plusieurs PDU supplémentaires peuvent être transmises à de brefs intervalles durant cette période d'initialisation.

Noter que cette solution peut n'être mise en œuvre que dans les IS, que dans les ES, ou dans les systèmes intermédiaires et d'extrémité. Cette décision est une question purement locale et peut être altérée par la gestion de système.

A.4	Optimisations pour la purge des redirections

Un ES va tenter de transmettre des NPDU à travers un IS sur lequel il a été redirigé jusqu'à expiration du temporisateur de garde spécifié dans al PDU RD, même si cet IS n'est plus joignable. Dans certaines circonstances, il est possible de faire mieux et de reconnaître au plus tôt l'existence d'un trou noir. En particulier, si l'ES s'attend à entendre des PDU ISH de la part de l'IS sur lequel il a été redirigé, et si le temporisateur de garde pour cet IS arrive à expiration, toute connaissance ce cet IS peut être oubliée par l'ES. Cela inclut toute les redirections, qui peuvent être purgées (voir la fonction de purge des anciennes redirection) quand bien même leurs temporisations ne seraient pas arrivées à expiration.