Groupe de travail Réseau	D. Katz, cisco	
Request for Comments : 1377	november 1992	
Catégorie  : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Protocole de contrôle de couche réseau OSI en point à point (OSINLCP)

Statut de ce mémoire
La présente RFC spécifie un protocole sur la voie de la normalisation approuvé par l'IAB pour la communauté de l'Internet, et qui appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l'édition en cours des "normes officielles de protocoles de l'IAB" pour l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé
Le protocole point à point (PPP) [1] fournit une méthode standard d'encapsulation des informations de protocole de couche réseau sur des liaisons point à point. PPP définit aussi un protocole de contrôle de laison extensible, et propose une famille de protocoles de contrôle de réseau (NCP, Network Control Protocol) pour établir et configurer différents protocoles de couche réseau.

Le présent document définit le NCP pour établir et configurer les protocoles de couche réseau OSI.

Le présent mémoire a été produit par le groupe de travail Protocole point à point de l'équipe d'ingénierie de l'Internet (IETF, Internet Engineering Task Force). Les commentaires sur ce mémoire devrait être soumis à la liste de diffusion ietf-ppp@ucdavis.edu .
Table des matières
1. Introduction	1
1.1 Protocoles de couche réseau OSI sur PPP	2
2. Protocole de contrôle de réseau PPP pour OSI	3
2.1 Envoi des NPDU OSI	3
2.2 Alignement de NPDU	3
2.3 Informations d'adressage de couche réseau	4
3. Options de configuration OSINLCP	4
3.1 Align-NPDU	4
Références	5
Remerciements	5
Considérations sur la sécurité	6
Adresse du président	6
Adresse de l'auteur	6

 	1.	Introduction

PPP a trois composants principaux :
1.	Une méthode d'encapsulation des datagrammes sur des liaisons en série.
2.	Un protocole de contrôle de liaison (LCP, Link Control Protocol) pour établir, configurer, et vérifier la connexion de liaison des données.
3.	Une famille de protocoles de contrôle de réseau (NCP, Network Control Protocol) pour établir et configurer différents protocoles de couche réseau.

Afin d'établir les communications sur une liaison point à point, chaque extrémité de la liaison PPP doit d'abord envoyer des paquets LCP pour configurer et vérifier la liaison de données. Après l'établissement de la liaison et que la négociation comme nécessaire des facilités facultatives par le LCP, PPP doit envoyer des paquets NCP pour choisir et configurer un ou plusieurs protocoles de couche réseau. Une fois que chacun des protocoles de couche réseau choisis a été configuré, les datagrammes provenant de chaque protocole de couche réseau peuvent être envoyés sur la liaison.

La liaison va rester configurée pour les communications jusqu'à ce que des paquets LCP ou NCP explicites closent la liaison, ou jusqu'à ce qu'un événement externe se produise (un temporisateur d'inactivité arrive à expiration ou une intervention de l'administrateur du réseau).

 	1.1	Protocoles de couche réseau OSI sur PPP
Un certain nombre de protocoles ont été définis pour la couche réseau de l'OSI, incluant le protocole de couche réseau sans connexion (CLNP, Connectionless Network Layer Protocol) (ISO 8473) [3], le protocole d'acheminement de système d'extrémité à système intermédiaire (ES-IS, End System to Intermediate System) (ISO 9542) [4], le protocole d'acheminement de système intermédiaire à système intermédiaire (IS-IS, Intermediate System to Intermediate System) (ISO 10589) [5], et le protocole d'acheminement inter domaines (IDRP, Inter-Domain Routeing Protocol) CD 10747) [6]. Généralement, ces protocoles ont été conçus pour fonctionner sur des protocoles de liaison de données non fiables tels que PPP.

Identifiant de protocole de couche réseau (NLPID, Network Layer Protocol Identifier) : les protocole de couche réseau OSI peuvent être distingués selon le premier octet de chaque unité de données de protocole réseau (NPDU, Network Protocol Data Unit) (c'est-à-dire un paquet) connu sous le nom d'identifiant de protocole de couche réseau (NLPID) qui est défini dans la norme ISO/TR 9577 [7]. Cela permet que les divers protocoles fonctionnent sur une liaison de données commune sans aucun discriminant en dessous de la couche réseau.

Protocole de couche réseau inactif : La norme ISO/TR 9577 réserve une valeur de NLPID de zéro pour représenter le "protocole de couche réseau inactif", défini dans la norme ISO 8473. Le protocole de couche réseau inactif NE DOIT PAS être utilisé sur PPP. Cela assure que quel que soit le protocole de couche réseau OSI utilisé, il aura une valeur de NLPID non zéro.

Protocole réseau en mode connexion : le protocole réseau en mode connexion OSI (ISO 8208) [8], en fait la couche paquet de la Recommandation UIT-T X.25, est destiné à fonctionner sur une liaison de données fiable, comme IEEE 802.2 de type II ou LAPB. Donc, le service de liaison de données non fiable fourni par PPP n'est pas approprié pour être utilisé avec ISO 8208.

Protocole réseau sans connexion (CLNP, ConnectionLess Network Protocol)  : le protocole réseau sans connexion offre un simple service de datagrammes non fiable très similaire à IP, et est conçu pour fonctionner sur un service de liaison de données non fiables, tel que celui fourni par PPP.

Protocole de système d'extrémité à système intermédiaire (ES-IS, End-System to Intermediate-System)  : les Hellos ES et les Hellos IS sont retransmis sur la base d'un temporisateur périodique (fondés sur l'expiration du "temporisateur de configuration"). Les informations de configuration ES et IS résultantes sont invalidées sur la base d'un temporisateur , fondé sur l'expiration du "temporisateur de garde" pour chaque élément d'information. La valeur du temporisateur de garde est réglé par la source de l'information, et transmise dans le champ Temps de garde du paquet ES-IS approprié. ISO 9542 recommande que le champ Temporisateur de garde soit réglé approximativement à deux fois le paramètre Temporisateur de configuration, de façon que même si chaque autre paquet Hello est perdu, les informations de configuration seront conservées (ce qui implique que le temporisateur de garde soit en fait réglé à un peu plus que deux fois le temporisateur de configuration).

Généralement, la recommandation de ISO 9542 est suffisante pour les liaisons PPP. Pour les liaison très peu fiables, il peut être nécessaire de régler le temporisateur de garde à un peu plus de trois fois le temporsateur de configuration pour s'assurer que la perte des informations de configuration reste un événement exceptionnel.

Les informations de redirection ne sont pas transmises sur les liaisons point à point, mais peuvent être transmises sur des sous réseaux de topologie générale, qui à leur tour peuvent utiliser PPP. Les informations de redirection sont envoyées sur la base de l'événement (sur la base d'un paquet CLNP transmis par un routeur en dehors de l'interface entrante) mais les informations de redirection sont invalidées sur la base d'un temporisateur. La perte d'une seule redirection peut résulter en ce qu'un paquet de données suivant soit envoyé au même routeur incorrect, qui va produire à nouveau la redirection. Cela opère de la même manière que les redirections ICMP pour les paquets IP, et ne pose aucun problème pour le fonctionnement sur les liaisons PPP.

Protocole de système intermédiaire à système intermédiaire (IS-IS)  : IS-IS permet des liaisons de diffusion (normalement des LAN), des liaisons point à point (comme PPP), et des liaisons de topologie générale (comme les réseaux X.25) qui sont modélisés comme une collection de liaisons point à point.

Il y a quatre types de paquets IS-IS : les paquets Hello IS-IS, les paquets d'état de liaison (LSP, Link State Packet), les paquets à numéro de séquence complet (CSNP, Complete Sequence Number Packet), et les paquets à numéro de séquence partiel (PSNP, Partial Sequence Number Packet).

Les messages IS-IS Hello sont transmis périodiquement sur les liaisons point à point (sur la base de l'expiration du temporisateur "ISISHello"). Les routeurs s'attendent à recevoir périodiquement les paquets IS-IS Hello. Spécifiquement, le paquet IS-IS Hello spécifie un "temps de garde". Si aucun Hello IS-IS n'est reçu sur la liaison correspondante pendant la période spécifiée, le routeur du voisinage est supposé avoir été déconnecté ou être mort. Il est très indésirable que les liaisons "clignotent" inutilement, ce qui implique que le temps de garde doit être assez grand pour qu'il soit très improbable qu'une liaison soit déclarée morte à cause de l'échec de réception d'un Hello IS-IS. Cela implique que faire fonctionner IS-IS sur des liaisons de données non fiables exige que le temps de garde soit supérieur à "k" fois le temporisateur de Hello IS-IS, où k est choisi de façon telle que la perte de k Hello IS-IS consécutifs soit rare. Si la qualité de la liaison est mauvaise, le temps de garde va devoir être augmenté ou le temps de "ISISHello" diminué.

Les LSP sont acquittés par le protocole IS-IS (via l'utilisation de paquets de numéro de séquence partiels). Un LSP perdu va être récupéré sans problème pourvu que les liaisons PPP soient traitées de la même façon que les autres liaisons point à point. Dans les rares occasions où un paquet de numéro de séquence partiel est perdu, il peut en résulter la retransmission d'un paquet d'état de liaison sur une seule liaison, mais cela ne va pas impacter le fonctionnement correct de l'algorithme d'acheminement.

Les CSNP sont envoyés au démarrage de la liaison sur une liaison en point à point. Cela n'a pas besoin d'être changé pour PPP. Si un fragment de CSNP est perdu au démarrage, c'est simplement la perte d'une optimisation – des LSP qui n'avaient pas besoin d'être transmis sur la liaison vont être transmis. Si un fragment de CSNP périodique est perdu, cela signifie simplement que la détection d'une corruption de faible probabilité de la base de données va prendre plus longtemps.

Les PSNP fonctionnent comme des accusés de réception (ACK). La perte d'un PSNP peut résulter en une retransmission inutile d'un LSP, mais cela n'empêche pas le fonctionnement correct du protocole d'acheminement.

Protocole d'acheminement inter-domaines (IDRP)  : IDRP est prévu pour fonctionner sur des liaisons de datagrammes, mais exige un échange fiable des informations de IDRP. Pour cette raison, IDRP contient des mécanismes de fiabilité incorporés qui assurent que les paquets seront reçus correctement.

 	2.	Protocole de contrôle de réseau PPP pour OSI

Le protocole de contrôle de couche réseau OSI (OSINLCP, OSI Network Layer Control Protocol) est chargé de configurer, activer, et désactiver les modules de protocole OSI sur les deux extrémités de la liaison point à point. OSINLCP utilise le même mécanisme d'échange de paquets que le protocole de contrôle de liaison (LCP, Link Control Protocol). Les paquets OSINLCP ne peuvent pas être échangés avant que PPP ait atteint la phase de protocole de couche réseau. Les paquets OSINLCP reçus avant que cette phase soit atteinte devraient être éliminés en silence.

Le protocole de contrôle de couche réseau OSI est exactement le même que le protocole de contrôle de liaison [1] avec les exceptions suivantes :

Modifications de trame  : le paquet peut utiliser toutes les modifications du format de trame de base qui ont été négociées durant la phase d'établissement de liaison.

Champ Protocole de couche de liaison des données : exactement un paquet OSINLCP est encapsulé dans le champ Information d'une trame de couche de liaison des données PPP où le champ Protocole indique le type hex 8023 (protocole de contrôle de couche réseau OSI).

Champ Code : seuls les codes 1 à 7 (Demande de configuration, Accusé de réception de configuration, Non accusé de réception de configuration, Rejet de configuration, Demande de terminaison, Accusé de réception de terminaison et Code de rejet) sont utilisés. Les autres codes devraient être traités comme non reconnus et devraient résulter en des codes de rejet.

Temporisations  : les paquets OSINLCP ne peuvent pas être échangés avant que PPP ait atteint la phase de Protocole de couche réseau. Une mise en œuvre devrait être prête à attendre que l'authentification et la détermination de qualité de liaison se finissent avant de faire une fin de temporisation dans l'attente d'un Accusé de réception de configuration ou autre réponse. Il est suggéré qu'une mise en œuvre n'abandonne qu'après une intervention de l'utilisateur ou un délai configurable.

Types d'option de configuration : OSINLCP a une option de configuration, qui est définie à la Section 3 ci-dessous.

 	2.1	Envoi des NPDU OSI
Avant qu'aucune unité de données de protocole réseau (NPDU, Network Protocol Data Unit) puisse être communiquée, PPP doit atteindre la phase Protocole de couche réseau, et le protocole de contrôle de couche réseau OSI doit atteindre l'état Ouvert.

Exactement une NPDU OSI est encapsulée dans le champ Information d'une trame de couche de liaison des données PPP où le champ Protocole indique le type hex 0023 (couche réseau OSI).

La longueur maximum d'une NPDU OSI transmise sur une liaison PPP est la même que la longueur maximum du champ Information d'une trame de couche de liaison des données PPP. Les NPDU plus grandes doivent être segmentées si nécessaire. Si un système souhaite éviter la segmentation et le réassemblage, il devrait utiliser des mécanismes de couche transport pour décourager les autres d'envoyer de grosses PDU.

 	2.2	Alignement de NPDU
Les protocoles OSI ont des problèmes d'alignement particuliers dus au fait qu'ils sont souvent encapsulés dans des protocoles de liaison des données avec des en-têtes de longueur impaire, tandis que PPP prend par défaut des en-têtes de longueur paire. Un routeur qui commute un paquet OSI peut trouver que le début du paquet tombe sur une limite de mémoire inappropriée quand le matériel utilisé pour transmettre le paquet à son prochain bond exige un alignement particulier. Cette situation peut être traitée par l'utilisation d'un bourrage de zéros en tête.

À l'envoi, une mise en œuvre PEUT insérer de un à trois octets de zéros entre l'en-tête PPP et la NPDU OSI. Ces octets de zéros réduisent de façon correspondante la longueur maximum de la NPDU qui peut être transmise.

À réception, ces octets à zéro en tête (si ils sont présents) DOIVENT être retirés. Sans considération de si le bourrage de zéros en tête est utilisé, une mise en œuvre DOIT aussi être capable de recevoir un paquet PPP avec tout alignement arbitraire de la NPDU.

 	2.3	Informations d'adressage de couche réseau
OSINLCP ne définit pas d'option de configuration sépatée pour l'échange des informations d'adresse de couche réseau OSI.  À la place, le protocole ES-IS, ISO 9542, devrait être utilisé. Ce protocole fournit un mécanisme pour déterminer la ou les adresses de couche réseau du voisin sur la liaison, ainsi que pour déterminer si le voisin est un système d'extrémité ou un système intermédiaire.

Un projet d'addendum à ES-IS [9] est en cours de définition à l'ISO pour ajouter la prise en charge de l'allocation dynamique d'adresses. Cet addendum a actuellement passé le stade formel de "Committee Draft" (CD).

 	3.	Options de configuration OSINLCP

Les options de configuration de OSINLCP permettent la négociation des paramètres désirables du protocole Internet. OSINLCP utilise le même format d'option de configuration que défini pour LCP [1], avec un ensemble d'options distinct.

Les valeurs les plus à jour du champ Type d'option OSINLCP sont spécifiées dans la plus récente RFC des "Numéros alloués" [2]. Les valeurs actuellement allouées sont :

      1       Align-NPDU

 	3.1	Align-NPDU
Description  : cette option de configuration donne un moyen pour que le receveur négocie un alignement particulier de la NPDU OSI. Une évidence empirique suggère que le plus grand déficit de temps pour le réalignement existe chez le receveur.

L'alignement est accompli par la combinaison de la compression d'en-tête PPP avec le bourrage de zéros en tête (voir ci-dessus). Il est recommandé que l'alignement soit entièrement par les combinaisons de compression d'en-tête chaque fois que possible. Par exemple, un alignement de 3 pourrait être réalisé en combinant les champs non compressés Adresse et Contrôle PPP (2 octets) avec un champ Protocole PPP compressé (1 octet).

Cette option est négociée séparément dans chaque direction. Un receveur qui n'a pas besoin de l'alignement NE DOIT PAS demander l'option. Un envoyeur qui désire l'alignement avant l'envoi DEVRAIT envoyer un Non accusé de configuration de la valeur appropriée.

Note : dans un environnement complexe, il pourrait y avoir plusieurs besoins contradictoires quant à l'alignement. Il est recommandé que le receveur demande l'alignement sur la base des besoins de la liaison de prochain bond de plus haut débit. Aussi, une plus grande efficacité pourra être obtenue en négociant en amont les valeurs demandées par les liaisons PPP en amont, car ces paquets n'auront pas besoin d'un changement d'alignement en transit.

La demande d'alignement est pour avis, et l'échec d'un accord sur un alignement NE DOIT PAS empêcher le OSINLCP d'atteindre l'état Ouvert. Par défaut, l'alignement est fait selon les besoins de l'envoyeur, et tous les receveurs DOIVENT être capables d'accepter les paquets avec tout alignement.

Vernaculaire : si on n'aime pas cette option, on peut refuser de la négocier, et on peut envoyer tout alignement possible. Cependant, si on accepte l'option d'alignement de l'homologue, on DOIT transmettre les paquets avec l'alignement décidé.

Le format de l'option de configuration Align-NPDU est montré ci-dessous. Les champs sont transmis de gauche à droite.

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |   Aligenment  |
+---------------+---------------+---------------+

Type  : 1

Longueur  : 3

Alignement  : ce champ spécifie le décalage du début de la NPDU OSI par rapport au début de l'en-tête de paquet PPP (non inclus les séquences de fanion qui peuvent se trouver devant).
Une valeur de 1 à 4 exige un décalage de cette longueur spécifique, modulo 4. Par exemple, une valeur de 1 exigerait qu'il n'y ait pas de bourrage quand les champs Adresse, Contrôle, et Protocole PPP sont compressés. Un octet de bourrage de zéros en tête serait nécessaire quand l'en-tête PPP est de taille complète.
Une valeur de 255 demande un décalage d'une longueur impaire (1 ou 3). Une valeur de 254 demande un décalage d'une longueur paire (2 ou 4). Si l'envoyeur n'est pas capable de faire varier dynamiquement la quantité de bourrage, il DOIT faire un accusé de réception négatif (NAK) avec une des deux valeurs spécifiques.

 	Références

[1] [RFC1331]	W. Simpson, "Protocole point à point (PPP)", mai 1992. (Obsolète, voir RFC1661 STD54)

[2] [RFC1340]	J. Reynolds et J. Postel, "Numéros alloués", STD 2, juillet 1992. (Obsolète, voir RFC1700, elle-même Historique)

[3]	ISO, "Information processing systems -- Data communications -- Protocol for providing the connectionless-mode network service", ISO 8473, 1988.

[4]	ISO, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 9542, 1988.

[5]	ISO, "Information processing systems -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 10589, 1990.

[6]	ISO, "Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO CD 10747, 1991.

[7]	ISO, "Information technology -- Telecommunications and information exchange between systems -- Protocol identification in the network layer", ISO/IEC TR9577:1990.

[8]	ISO, "Information processing systems -- Data communications -- X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984.

[9]	Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery of OSI NSAP Addresses by End Systems)", SC6/N7248.

 	Remerciements

Une partie du texte de ce document est tiré de documents précédents produits par le groupe de travail Protocole point à point de l'équipe d'ingénierie de l'Internet (IETF).

Des remerciements particuliers à Ross Callon (DEC), et Cyndi Jung (3Com), pour leurs contributions au texte et aux suggestions de conception fondées sur leur expérience de mise en œuvre.

Merci aussi à Bill Simpson de ses efforts d'édition et de formatage, à la fois pour ce document et pour PPP en général.

 	Considérations sur la sécurité

Les questions de sécurité ne sont pas discutées dans le présent mémoire.

 	Adresse du président

Le groupe travail peut être contacté via le présifent actuel :

Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682

téléphone : (916) 676-1147
mél : brian@lloyd.com 

 	Adresse de l'auteur

Les questions sur le présent mémoire peuvent aussi êtrree adressées à :

Dave Katz
cisco Systems, Inc.
1525 O'Brien Dr.
Menlo Park, CA  94025

téléphone : (415) 688-8284
mél : dkatz@cisco.com