Groupe de travail Réseau

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

Le protocole point à point (PPP) [1] fournit une méthode standard pour le transport de datagrammes multi-protocoles sur des liaisons point à point. Le présent document décrit l'utilisation de PPP sur des circuits commutés du réseau numérique à intégration de services (RNIS).

Le présent document a été produit par le groupe de travail Protocole point à point de l'Équipe d'ingénierie de l'Internet (IETF). Les commentaires devraient être soumis à la liste de diffusion ietf-ppp@merit.edu.

La présente spécification est destinée aux mises en œuvre qui désirent utiliser l'encapsulation PPP sur liaisons RNIS point à point. PPP n'est pas destiné aux environnements multipoint ou multi-accès.

"Il est clair qu'il n'y aura vraisemblablement jamais un seul RNIS monolithique couvrant le monde entier." [3] L'objectif du présent document est de décrire quelques mises en œuvre courantes, choisies dans la grande diversité des alternatives actuelles, dans un effort de promotion de l'interopérabilité.

Table des matières

1. Introduction 1

2. Exigences pour la couche physique 2

3. Tramage 3

4. Signalisation hors bande 3

5. Détails de configuration 3

Références 4

PPP a été conçu comme méthode standard pour communiquer sur des liaisons point à point. Les développement initiaux se sont faits sur de courtes lignes locales, des liaisons louées, et des lignes du service téléphonique traditionnel (POTS, plain old telephone service) utilisant des modems. Alors que de nouveaux services par paquets et des lignes à plus grande vitesse sont introduites, PPP est facilement déployé aussi dans ces environnements.

La présente spécification est principalement concernée par l'utilisation de l'encapsulation de PPP sur les liaisons RNIS. Comme le canal B du RNIS est par définition un circuit point à point, l'utilisation de PPP est bien adaptée sur ces liaisons.

L'interface de débit primaire (PRI, Primary Rate Interface) du RNIS peut prendre en charge de nombreuses liaisons de canal B concurrentes. Les mécanismes LCP (Link Control Protocol = protocole de contrôle des liaisons) et NCP (Network Control Protocol= protocole de commande réseau) de PPP sont particulièrement utiles dans cette situation en réduisant ou éliminant la configuration manuelle, et en facilitant une communication aisée entre diverses mises en œuvre.

Le canal B RNIS peut aussi être utilisé pour l'envoi de paquets PPP avec un tramage convenable, mais il est limité en bande passante et restreint souvent les liaisons de communication au commutateur local.

La terminologie du RNIS peut prêter à confusion. Voici une représentation graphique simple des points utilisés dans les descriptions qui suivent:

PPP traite les canaux RNIS comme des liaisons synchrones orientées bit ou octet. Ces liaisons DOIVENT être bidirectionnelles, mais PEUVENT être des liaisons spécialisées ou des circuits commutés.

PPP présente une interface d'octet à la couche physique. Il n'y a aucune disposition pour la fourniture ou l'acceptation de sous octets. Le flux d'octet est appliqué principalement aux points de référence R ou T.

PPP n'impose aucune restriction sur le taux de transmission, en dehors de celles de l'interface du canal RNIS particulier.

PPP n'exige pas l'utilisation de signaux de contrôle. Lorsque ils sont disponibles, l'utilisation de tels signaux peut permettre de meilleures fonctionnalités et performances. Les implications en sont discutées en [2]. Les signaux de contrôle PEUVENT être exigés par certaines des techniques de tramage décrites, et sortent du domaine d'application de la présente spécification.

La définition des divers codages et embrouillages est de la responsabilité de l'équipement ETTD/ETCD utilisé, et sort du domaine d'application de la présente spécification.

Bien que PPP fonctionne sans considération de la représentation du flux binaire sous-jacent, l'absence de normes pour la transmission entraverait l'interopérabilité aussi sûrement que l'absence de normes sur les liaisons de données. L'interface LAPD de canal D exige le codage NRZ (Non Return to Zero, non retour à zéro) au point de référence T. Donc, par défaut, il est recommandé que NRZ soit utilisé sur l'interface de canal B au point de référence T. Cela permettra un échange facile des trames entre les canaux B et D.

Lorsque la configuration du codage est permise, NRZI (non retour à zéro inversé) est recommandé comme solution de remplacement afin de s'assurer d'une densité minimum de uns lorsque c'est exigé sur le canal B libre, avec un avertissement en ce qui concerne FCS (Frame Check Sequence = séquence de contrôle de trame) [2].

Historiquement, certaines mises en œuvre ont utilisé le NRZ inversé (en commutant simplement le sens des marques et des espaces), afin de s'assurer d'une densité minimum de uns avec la synchronisation binaire HDLC. L'utilisation de NRZ inversé est déconseillée.

Les mises en œuvre qui désirent interopérer avec plusieurs codages PEUVENT choisir de détecter automatiquement les codages. La détection automatique de codage est particulièrement importante pour les interfaces de débit primaire, pour éviter une pré-configuration considérable. Seuls les codages simples sont actuellement distingués.

La seule méthode de détection fiable disponible est de commuter de modes entre les codages pris en charge.

Transmission du LCP (Link Control Protocol, protocole de contrôle des liaisons)

La demande Configure-Request DEVRAIT être essayée deux fois pour chaque mode avant de passer au circuit suivant. Cela assure qu'un délai suffisant est disponible pour permettre l'arrivée d'une réponse de l'homologue.

Le paramètre Max-Configure DOIT être établi de telle façon que les tentatives cumulées ne résultent pas en un délai supérieur à 59 secondes avant la déconnexion. Il est préférable que la limite usuelle de 30 secondes soit observée.

Par pré-configuration, PPP PEUT aussi être utilisé avec d'autres codages. Parce qu'il est difficile de les distinguer, il n'est pas recommandé de détecter automatiquement ces codages.

Les adaptateurs de terminaux conformes à V.120 [4] peuvent être utilisés comme une simple interface avec des stations de travail. Le tramage HDLC (high-level data link control, commande de liaison des données de haut niveau) asynchrone [2] est accepté au point de référence R. L'adaptateur de terminal fournit la conversion asynchrone/synchrone. Plusieurs canaux B peuvent être utilisés en parallèle. Malheureusement, V.120 a un mode de tramage à lui pour l'adaptation de débit, qu'il est difficile de distinguer du relais de trame, et qui peut tromper la détection de trame dans la bande. V.120 n'est pas interopérable avec les liaisons à synchronisation binaire, car V.120 ne fournit pas la conversion de bourrage d'octet à bourrage de bit. Donc, V.120 est déconseillé en faveur de normes plus modernes, comme "PPP en relais de trame".

Le "groupe sur l'interopérabilité de la bande passante à la demande" a défini une proposition appelée BONDING. Plusieurs canaux B peuvent être utilisés en parallèle. BONDING a une période d'initialisation propre, qui pourrait entrer en conflit avec la technique de détection simple décrite ci-dessus, et exige une configuration individuelle considérable dans certaines mises en œuvre courantes lorsque plusieurs canaux B sont impliqués. Il est recommandé d'utiliser la procédure PPP multi-liaison plutôt que BONDING.

Pour les canaux B, en l'absence de pré-configuration, la mise en œuvre DOIT d'abord utiliser HDLC [2] à synchronisation binaire, par opposition à d'autres tramages, pour l'établissement initial de la liaison. Cela suppose que les communications par circuit commuté sont généralement de [hôte | routeur] à [hôte | routeur].

Par pré-configuration, le HDLC [2] à synchronisation binaire est recommandé lorsque les interfaces d'équipement de terminaison sont directement au point de référence T, et que les limites d'octet sont disponibles au moment de la mise en trame. Une telle exigence sera vraisemblablement très intégrée, et l'élimination des matériels à synchronisation binaire peut réduire le compte de parties, ce qui résultera en des interfaces de moindre coût et de plus simples configurations. HDLC à synchronisation d'octet DOIT être utilisé avec le codage de bit NRZ.

Pour les canaux D, aucun service de données n'est attendu par défaut. En pré-configuration, le tramage de "PPP sur X.25" ou "PPP en relais de trame" PEUT être utilisé.

En dépit du fait que HDLC, LAPB, LAPD, et LAPF sont théoriquement distinguables, plusieurs méthodes de tramage NE DEVRAIENT PAS être utilisées concurremment sur le même canal RNIS. Il n'est pas exigé que PPP reconnaisse des techniques alternatives de tramage, ou passe d'une technique de tramage à une autre sans une configuration spécifique.

L'expérience a montré que l'élément d'information LLC (Logical Link Control, commande de liaison logique) n'est pas transmis de bout en bout de façon fiable. Le déploiement de commutateurs compatibles est trop limité, et les politiques d'abonnement aux fournisseurs sont trop diverses. Donc, on NE DEVRAIT PAS s'appuyer sur la transmission de l'élément d'information LLC (LLC-IE) pour la détermination du tramage ou du codage.

Aucune valeur de LLC-IE appartenant à PPP n'a été allouée. Toute autre valeur reçue n'est pas valide pour les liaisons PPP, et peut être ignorée pour le service PPP.

Comme mesure administrative de remplacement, plusieurs numéros d'annuaire peuvent pointer sur la même facilité d'accès physique, en liant des services particuliers à chaque numéro d'annuaire. Il a été prouvé que l'identifiant de l'appelant est fourni de façon fiable par le commutateur local.

Lorsque un identifiant d'appelé est utilisé, ou lorsque une future valeur de LLC-IE sera allouée à PPP et que la valeur PPP est reçue, si le LCP n'a pas eu l'événement administratif Open, l'appel DOIT être rejeté. Les receveurs NE DOIVENT PAS accepter un appel entrant, et seulement fermer le circuit ou ignorer les paquets provenant du circuit.

Les options de configuration sync recommandées pour LCP s'appliquent aux liaisons RNIS.

Le réseau typique qui alimente la liaison aura vraisemblablement une MRU de 1500, 2048 ou supérieure. Pour éviter la fragmentation, l'unité de transmission maximum (MTU, Maximum-Transmission-Unit) à la couche réseau NE DEVRAIT PAS excéder 1500, sauf si une MRU d'homologue de 2048 ou supérieure est spécifiquement négociée.

Au lieu d'une valeur constante pour le temporisateur de redémarrage (Restart), la méthode de la temporisation exponentielle est recommandée. Le temporisateur de redémarrage DEVRAIT être de 250 millisecondes pour la valeur initiale, et de 3 secondes pour la valeur finale.

Les mises en œuvre qui comportent des dispositifs de numérotation persistante, tels que la "numérotation à la demande" ou la "renumérotation", DEVRAIENT utiliser des mécanismes pour limiter leur persistance. Des exemples de tels mécanismes sont la temporisation exponentielle, et l'élimination des files d'attentes de paquets après l'échec de l'achèvement de l'établissement de la liaison. Dans certaines mises en œuvre, l'élimination de la file d'attente de transmission peut temporairement supprimer le stimulus de réessai de la connexion.

[1] W. Simpson, éditeur, "Protocole point à point (PPP)", RFC 1548, Daydreamer, décembre 1993.

[2] W. Simpson, éditeur, "PPP en tramage HDLC", RFC 1549, Daydreamer, décembre 1993.

[4] Recommandations CCITT I.465 et V.120, "Communications de terminaux de données sur le réseau téléphonique avec des dispositions pour le multiplexage statistique", Livre bleu du CCITT, volume VIII, fascicule VIII.1, 1988.

Ce concept a été inspiré par les travaux antérieurs de C. Frost, B. Gorsline, D. Leifer, K. Muramaki, S. Sheldon, K. Sklower et T. Sugawara.

Merci à Oliver Korfmacher (NetCS) pour les considérations relatives à l'Europe, à Dory Leifer (Université du Michigan) pour les précisions techniques et la signalisation de la partie appelante, et à Vernon Schryver (Silicon Graphics) pour le traitement des mauvaises configurations et fins de temporisation des liaisons.

Des remerciements particuliers à Morning Star Technologies qui a fourni les ressources informatiques et l'accès réseau pour la rédaction de la présente spécification.

Groupe de travail Réseau	W. A. Simpson, Daydreamer
Request for Comments : 1618	mai 1994
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle