3. Couche Liaison de Données (Link Layer)
3. Couche Liaison de Données (Link Layer)
[INTRO:1] couvre les normes de la couche liaison (implémentation d'IP sur diverses couches liaison, ARP, etc.), mais ce document prévoit que les exigences relatives à la couche liaison seront couvertes dans un document distinct dédié à cette couche. Ce document sur les exigences de la couche liaison s'applique à la fois aux hôtes et aux routeurs. Par conséquent, ce document ne rend pas obsolètes les sections de [INTRO:1] traitant des problèmes de couche liaison.
3.1 Introduction
Les routeurs ont essentiellement les mêmes exigences de protocole de couche liaison que les autres types de systèmes Internet. Ces exigences sont décrites au chapitre 3 de Requirements for Internet Gateways [INTRO:1]. Les routeurs DOIVENT se conformer à ces exigences et DEVRAIENT se conformer à ses recommandations. Certains éléments de ce document étant quelque peu obsolètes, des exigences et clarifications supplémentaires sont incluses ci-dessous.
DISCUSSION
Il est prévu que la communauté Internet élabore une norme d'exigences pour la couche liaison Internet qui remplacera ce chapitre ainsi que le chapitre intitulé « INTERNET LAYER PROTOCOLS » de [INTRO:1].
3.2 Interface Couche Liaison / Couche Réseau (Link/Internet Layer Interface)
Ce document ne tente pas de spécifier l'interface entre la couche liaison et les couches supérieures. Cependant, notez que d'autres parties de ce document, en particulier le chapitre 5, exigent que diverses informations soient transmises à travers cette frontière de couche.
Dans cette section, les définitions suivantes sont utilisées :
Adresse physique source (Source physical address)
L'adresse physique source est l'adresse de couche liaison de l'hôte ou du routeur depuis lequel le paquet a été reçu.
Adresse physique de destination (Destination physical address)
L'adresse physique de destination est l'adresse de couche liaison vers laquelle le paquet a été envoyé.
Pour chaque paquet reçu, les informations devant être transmises de la couche liaison à la couche réseau sont les suivantes :
(1) Le paquet IP [5.2.2]
(2) La longueur de la partie données de la trame de couche liaison (c'est-à-dire, à l'exclusion de la trame de couche liaison elle-même) [5.2.2]
(3) L'identification de l'interface physique sur laquelle le paquet IP a été reçu [5.2.3], et
(4) La classification de l'adresse physique de destination du paquet en tant qu'unicast, broadcast ou multicast de couche liaison [4.3.2], [5.3.4]
De plus, la couche liaison DEVRAIT fournir :
(5) L'adresse physique source
Pour chaque paquet à envoyer, les informations devant être transmises de la couche réseau à la couche liaison sont les suivantes :
(1) Le paquet IP [5.2.1]
(2) La longueur du paquet IP [5.2.1]
(3) L'interface physique de destination [5.2.1]
(4) L'adresse IP du prochain saut (next-hop IP address) [5.2.1]
De plus, la couche réseau DEVRAIT fournir :
(5) La valeur de priorité de couche liaison [5.3.3.2]
Si un paquet à envoyer provoque une erreur liée à la priorité de couche liaison, la couche liaison DOIT en informer la couche réseau [5.3.3.3].
3.3 Problèmes Spécifiques (Specific Issues)
3.3.1 Encapsulation Trailer (Trailer Encapsulation)
Un routeur pouvant se connecter à un réseau Ethernet 10 mégabits PEUT recevoir et retransmettre des paquets Ethernet utilisant l'encapsulation trailer (encapsulation de fin de trame) décrite dans [LINK:1]. Cependant, un routeur NE DEVRAIT PAS initier des paquets avec encapsulation trailer. Un routeur NE DOIT PAS initier des paquets avec encapsulation trailer sans avoir d'abord vérifié, à l'aide des mécanismes décrits dans [INTRO:2], que la destination directe du paquet est capable et désireuse d'accepter des paquets avec encapsulation trailer. Un routeur NE DEVRAIT PAS (en utilisant ces mécanismes) accepter de recevoir des paquets avec encapsulation trailer.
3.3.2 Protocole de Résolution d'Adresses - ARP (Address Resolution Protocol)
Un routeur implémentant ARP DOIT se conformer aux exigences de [INTRO:2] et DEVRAIT s'y conformer inconditionnellement.
La couche liaison NE DOIT PAS signaler une erreur de destination inaccessible à IP au seul motif qu'il n'existe pas d'entrée dans le cache ARP pour la destination. Pendant l'exécution d'une séquence de requête/réponse ARP, un petit nombre de datagrammes DEVRAIT être mis en file d'attente temporairement, et une réponse de destination inaccessible DEVRAIT être envoyée pour l'un des datagrammes mis en file d'attente uniquement si cela s'avère infructueux.
Un routeur NE DOIT PAS faire confiance à une réponse ARP affirmant que l'adresse de couche liaison d'un autre hôte ou routeur est une adresse broadcast ou multicast.
3.3.3 Coexistence Ethernet et 802.3 (Ethernet and 802.3 Coexistence)
Un routeur pouvant se connecter à un réseau Ethernet 10 mégabits DOIT se conformer aux exigences Ethernet de [INTRO:2] et DEVRAIT s'y conformer inconditionnellement.
3.3.4 Unité de Transmission Maximale - MTU (Maximum Transmission Unit)
Le MTU (Maximum Transmission Unit, unité de transmission maximale) de chaque interface logique DOIT être configurable dans la plage de MTU valide pour cette interface.
De nombreux protocoles de couche liaison définissent une taille de trame maximale pouvant être transmise. Dans ce cas, un routeur NE DOIT PAS autoriser la configuration d'un MTU tel qu'il permettrait l'envoi de trames plus grandes que ce que le protocole de couche liaison autorise. Cependant, un routeur DEVRAIT être capable de recevoir des paquets aussi grands que la taille de trame maximale, même si celle-ci est supérieure au MTU.
DISCUSSION
Notez qu'il s'agit d'une exigence plus stricte que celle imposée aux hôtes par [INTRO:2]. [INTRO:2] exige que le MTU de chaque interface physique soit configurable.
Si un réseau utilise un MTU inférieur à la taille de trame maximale de la couche liaison, un routeur peut recevoir des paquets plus grands que le MTU provenant d'hôtes mal configurés et non complètement initialisés. Le principe de robustesse indique que le routeur DEVRAIT, dans la mesure du possible, recevoir ces paquets normalement.
3.3.5 Protocole Point à Point - PPP (Point-to-Point Protocol)
Contrairement à [INTRO:1], il existe désormais un protocole de ligne point à point standard sur Internet : le Point-to-Point Protocol (PPP, protocole point à point), défini dans [LINK:2], [LINK:3], [LINK:4] et [LINK:5].
Une interface point à point (point-to-point interface) est une interface conçue pour transmettre des données sur une ligne point à point. Ces interfaces comprennent les lignes téléphoniques, louées, dédiées ou directes (2 fils ou 4 fils), et peuvent utiliser des circuits virtuels sur des canaux point à point ou des interfaces multiplexées (comme ISDN). Elles utilisent généralement des interfaces modem standardisées ou des interfaces série bit (telles que RS-232, RS-449 ou V.35) avec une horloge synchrone ou asynchrone. Les interfaces multiplexées disposent généralement d'interfaces physiques spéciales.
Une interface série générique (general serial interface) utilise le même support physique que les lignes point à point, mais prend en charge l'utilisation de réseaux de couche liaison et de connexions point à point. Les réseaux de couche liaison (tels que X.25 ou Frame Relay) utilisent des spécifications alternatives de couche liaison IP.
Un routeur implémentant des interfaces point à point ou série génériques DOIT IMPLÉMENTER PPP.
Toutes les interfaces série génériques d'un routeur DOIVENT prendre en charge PPP. Un routeur PEUT permettre la configuration d'une ligne pour utiliser un protocole de ligne point à point autre que PPP. Une interface point à point DEVRAIT utiliser PPP par défaut lorsqu'elle est activée, ou exiger la configuration du protocole de couche liaison avant l'activation. Une interface série générique DEVRAIT exiger la configuration du protocole de couche liaison avant l'activation.
3.3.5.1 Introduction
Cette section fournit des conseils aux implémenteurs de routeurs pour leur permettre d'assurer l'interopérabilité avec d'autres routeurs utilisant PPP sur des liaisons synchrones ou asynchrones.
Il est essentiel que les implémenteurs comprennent la sémantique du mécanisme de négociation d'options. Les options constituent un moyen pour le dispositif local d'indiquer au pair distant ce qu'il est prêt à accepter de ce pair, et non ce qu'il souhaite envoyer. Le pair distant peut décider d'envoyer ce qui lui convient le mieux dans l'ensemble des options que le dispositif local a déclaré pouvoir accepter. Par conséquent, il est tout à fait acceptable et normal que le pair distant acquitte (ACK) toutes les options indiquées dans une LCP Configuration Request (CR), même si le pair distant ne prend en charge aucune de ces options. Encore une fois, les options constituent un mécanisme permettant à chaque partie d'indiquer à son pair ce qu'elle est prête à accepter, pas nécessairement ce qu'elle enverra.
3.3.5.2 Options du Protocole de Contrôle de Liaison - LCP (Link Control Protocol Options)
Le PPP Link Control Protocol (LCP, protocole de contrôle de liaison) offre de nombreuses options pouvant être négociées. Ces options comprennent notamment : la compression des champs adresse et contrôle, la compression du champ protocole, la cartographie des caractères asynchrones (Asynchronous Control Character Map, ACCM), le Maximum Receive Unit (MRU, unité de réception maximale), le Link Quality Monitoring (LQM, surveillance de la qualité de liaison), le numéro magique (magic number, pour la détection de bouclage), le Password Authentication Protocol (PAP, protocole d'authentification par mot de passe), le Challenge Handshake Authentication Protocol (CHAP, protocole d'authentification par défi-réponse) et le Frame Check Sequence (FCS, séquence de vérification de trame) sur 32 bits.
Un routeur PEUT utiliser la compression des champs adresse/contrôle sur des liaisons synchrones ou asynchrones. Un routeur PEUT utiliser la compression du champ protocole sur des liaisons synchrones ou asynchrones. Un routeur indiquant qu'il peut accepter ces compressions DOIT également être capable d'accepter des informations d'en-tête PPP non compressées.
DISCUSSION
Ces options contrôlent l'apparence de l'en-tête PPP. Normalement, un en-tête PPP est composé d'un champ adresse, d'un champ contrôle et d'un champ protocole. Sur une ligne point à point, l'adresse est 0xFF, signifiant « broadcast ». Le champ contrôle est 0x03, signifiant « information non numérotée ». L'identifiant de protocole (Protocol Identifier) est une valeur sur 2 octets indiquant le contenu de la zone de données de la trame. Lorsqu'un système négocie la compression des champs adresse et contrôle, il indique à son pair qu'il est prêt à accepter des trames PPP avec ou sans ces champs en tête. Cela ne signifie pas que l'émetteur supprimera ces champs dans les trames qu'il envoie.
Lorsqu'un système négocie la compression du champ protocole, il indique qu'il est prêt à recevoir le champ protocole compressé sur 1 octet lorsque cela est légal. L'émetteur n'est pas obligé de le faire.
L'utilisation de la compression des champs adresse/contrôle est incompatible avec l'utilisation du mode numéroté (fiable) de PPP.
IMPLEMENTATION
Certains matériels ne gèrent pas bien les informations d'en-tête de longueur variable. Dans ce cas, il est préférable que le pair distant envoie un en-tête PPP complet. Une implémentation peut garantir cela en n'envoyant pas au pair distant les options de compression des champs adresse/contrôle et du champ protocole. Même si le pair distant indique qu'il peut accepter des en-têtes compressés, le routeur local n'est pas obligé d'envoyer des en-têtes compressés.
Un routeur DOIT négocier l'Asynchronous Control Character Map (ACCM, cartographie des caractères de contrôle asynchrones) pour les liaisons PPP asynchrones, mais NE DEVRAIT PAS négocier l'ACCM pour les liaisons synchrones. Si un routeur reçoit une demande de négociation de l'ACCM sur une liaison synchrone, il DOIT acquitter (ACKnowledge) cette option puis l'ignorer.
DISCUSSION
Certaines implémentations proposent des modes de fonctionnement synchrone et asynchrone en utilisant le même code pour la négociation d'options. Dans ce cas, l'une ou l'autre partie peut envoyer l'option ACCM sur une liaison synchrone.
Un routeur DEVRAIT négocier correctement le maximum receive unit (MRU, unité de réception maximale). Même si un système a négocié un MRU inférieur à 1 500 octets, il DOIT être capable de recevoir des trames de 1 500 octets.
Un routeur DEVRAIT négocier et activer l'option link quality monitoring (LQM, surveillance de la qualité de liaison).
DISCUSSION
Cette note ne spécifie pas de politique pour déterminer si la qualité de liaison est suffisante. Cependant, il est important que les routeurs désactivent les liaisons défectueuses (voir la section [3.3.6]).
Un routeur DEVRAIT implémenter et négocier l'option magic number (numéro magique) pour la détection de bouclage.
Un routeur PEUT prendre en charge les options d'authentification (PAP - Password Authentication Protocol, protocole d'authentification par mot de passe, et/ou CHAP - Challenge Handshake Authentication Protocol, protocole d'authentification par défi-réponse).
Un routeur DOIT prendre en charge le frame check sequence (FCS, séquence de vérification de trame) CRC 16 bits et PEUT prendre en charge le CRC 32 bits.
3.3.5.3 Options du Protocole de Contrôle IP - IPCP (IP Control Protocol Options)
Un routeur PEUT proposer d'effectuer la négociation d'adresse IP. Un routeur DOIT accepter le refus (REJect) d'effectuer la négociation d'adresse IP de la part d'un pair.
Un routeur fonctionnant à des vitesses de liaison inférieures ou égales à 19 200 BPS DEVRAIT implémenter et proposer la compression d'en-tête Van Jacobson. Un routeur implémentant la compression VJ DEVRAIT implémenter un contrôle administratif permettant de l'activer ou de la désactiver.
3.3.6 Test d'Interface (Interface Testing)
Un routeur DOIT disposer d'un mécanisme permettant au logiciel de routage de déterminer si une interface physique est en état d'envoyer des paquets. Pour les interfaces multiplexées ouvrant des circuits virtuels permanents vers un ensemble limité de voisins, le routeur DOIT également être capable de déterminer si un circuit virtuel est opérationnel. Un routeur DEVRAIT disposer d'un mécanisme permettant au logiciel de routage de déterminer la qualité d'une interface physique. Un routeur DOIT disposer d'un mécanisme pour notifier le logiciel de routage lorsqu'une interface physique devient disponible ou indisponible pour l'envoi de paquets à la suite d'une opération administrative. Un routeur DOIT disposer d'un mécanisme pour notifier le logiciel de routage lorsqu'il détecte qu'une interface de niveau liaison est devenue disponible ou indisponible pour quelque raison que ce soit.
DISCUSSION
Il est très important qu'un routeur dispose d'un mécanisme opérationnel pour déterminer si une connexion réseau fonctionne correctement. L'incapacité à détecter la perte d'une liaison, ou l'absence de mesures appropriées lors de la détection d'un problème, peut entraîner l'apparition de trous noirs (blackholes).
Les mécanismes pouvant être utilisés pour détecter les problèmes de connexion réseau varient considérablement selon le protocole de couche liaison utilisé et le matériel d'interface. L'objectif est de maximiser la capacité à détecter les pannes dans les limites imposées par la couche liaison.