Transmission des datagrammes IP sur le service SMDS

Statut du présent mémoire

Le présent mémoire définit un protocole pour la transmission de paquets IP et ARP sur un réseau de service de données commutées à plusieurs mégabits (SMDS, Switched Multi-megabit Data Service) configuré comme un sous-réseau IP logique. La présente RFC spécifie un protocole en cours de normalisation par l’IAB pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se référer à la dernière édition des "Normes officielles de protocole de l’IAB" 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.

Résumé

Le présent mémoire décrit une utilisation initiale de IP et ARP dans un environnement de service SMDS configuré comme un sous-réseau IP logique (LIS, Logicial IP subnetwork) (décrit ci-dessous). La méthode d’encapsulation utilisée est décrite, ainsi que diverses questions spécifiques du service. Le présent mémoire n’exclut pas un traitement ultérieur du service SMDS dans des configurations autres que LIS ; en particulier, des configurations publiques ou interentreprises peuvent être traitées différemment et seront décrites dans des documents ultérieurs. Le présent document ne considère que les stations terminales ou routeurs directement connectés sur IP ; les questions soulevées par un pontage de niveau MAC sont en dehors du domaine d’application du présent document.

Remerciement

Le présent mémoire doit beaucoup à la fois pour les concepts et le texte au document [4], écrit par Jon Postel et Joyce K. Reynolds de l’ISI et au document [5], écrit par David Katz de Merit, Inc. Les auteurs tiennent aussi à remercier de ses contributions le groupe de travail IP Over SMDS Service de l’Internet Engineering Task Force.

Conventions

Les conventions textuelles suivantes sont utilisées dans les éléments de la spécification du document :

o DOIT, DEVRA, ou OBLIGATOIRE – l’élément est une exigence absolue de la spécification.

o DEVRAIT ou RECOMMANDÉ – l’élément devrait généralement être suivi sauf circonstances exceptionnelles.

o PEUT ou FACULTATIF – l’élément est vraiment facultatif et sera suivi ou ignoré selon les besoins du développeur.

Introduction

Le but de la présente spécification est de permette des mises en œuvre compatibles et interopérables pour la transmission des datagrammes IP et des demandes et réponses ARP.

Les caractéristiques du service SMDS et du protocole d’interface SMDS (SIP, SMDS Interface Protocol) sont présentées dans les documents [3], [6], et [7]. En bref, le service SMDS est un service sans connexion, public, de données en paquets commutés. Le fonctionnement et les caractéristiques su service SMDS sont similaires à ceux des réseaux de données à grande vitesse tels que les LAN :

o Le service SMDS effectue un transfert de paquet de datagramme, dans lequel chaque unité de données est traitée et commutée séparément sans établissement préalable d’une connexion réseau.

o Le service SMDS offre un débit élevé et de faibles délais, fournit un transport transparent et livre jusqu’à 9 188 octets d’informations d’utilisateur en une seule transmission.

o Il n’est pas fourni de mécanisme explicite de commande de flux ; à la place, le taux de transfert des informations sur les chemins d’accès est contrôlé à la fois dans la direction abonné vers réseau et dans la direction réseau vers abonné grâce à l’utilisation d’un mécanisme de mise en application de classes d’accès.

o Des paquets peuvent être transférés aussi bien en envoi individuel que groupé (diffusion groupée).

o En plus de ces caractéristiques de LAN, un ensemble de dispositifs de service relatifs à l’adressage (validation de l’adresse de source, examen de l’adresse de source et de destination) est fourni pour permettre à un abonné ou ensemble d’abonnés de créer un réseau privé logique, ou un groupe fermé d’usagers, sur le service SMDS. Le contrôle d’accès fourni par le mécanisme de groupe fermé d’usagers est apporté par le fournisseur de service SMDS conformément aux spécifications établies dans le document [3].

o Les adresses SMDS sont de 60 bits plus un type d’adresse de 4 bits. Le sous-champ Type d’adresse occupe les 4 bits de plus fort poids des champs d’adresse de destination et de source de l’unité de données de protocole (PDU) SIP de niveau 3. Il contient la valeur 1100 pour indiquer une adresse individuelle et la valeur 1110 pour une adresse de groupe de 60 bits.

Le protocole d’interface SMDS se fonde sur la norme 802.6 de l’IEEE, Protocole MAC sans connexion de double bus à file d'attente répartie (DQDB, Distributed Queue Dual Bus ) [8]. La couche de service SMDS correspond à la sous-couche MAC 802 de l’IEEE. Le reste du service de liaison des données est fourni par le service de commande de liaison logique (LLC) de IEEE 802.2 [9]. La pile de services résultante est illustrée à la Figure 1 :

Figure 1. Pile de protocole pour IP sur service SMDS

Le présent mémoire décrit une utilisation initiale de IP et ARP dans un environnement de service SMDS configuré comme un sous-réseau logique IP (décrit ci-dessous). Il n’exclut pas un traitement ultérieur du service SMDS dans des configurations autres que de sous-réseaux IP logiques ; en particulier, des configurations publiques ou inter entreprises peuvent être traitées différemment et seront décrites dans des documents à venir. Le présent document ne traite pas des questions qui se rapportent à l’interopérabilité transparente de couche de liaison des données.

Configuration de sous-réseau logique IP

Ce paragraphe décrit le scénario d’un service SMDS configuré avec plusieurs sous-réseaux IP logiques, LIS (décrits ci-dessous). Le scénario ne prend en considération que les stations terminales ou routeurs directement connectés à IP ; les questions soulevées par le pontage de niveau MAC sont en dehors du domaine d’application de ce document.

Dans le scénario LIS, chaque entité séparée administrativement configure ses hôtes au sein d’un sous-réseau IP logique clos. Chaque LIS fonctionne et communique indépendamment des autres LIS sur le même réseau qui fournit SMDS. Les hôtes connectés à SMDS communiquent directement avec les autres hôtes au sein du même LIS. La communication avec les hôtes extérieurs à un LIS individuel est fournie via un routeur IP. Ce routeur pourrait être une simple station rattachée au service SMDS, qui a été configurée pour être membre des deux sous-réseaux IP logiques. Cette configuration résulte en un certain nombre de LIS disjoints fonctionnant sur le même réseau qui prend en charge le service SMDS. Il est reconnu qu’avec cette configuration, des hôtes de réseaux IP différents vont communiquer via un routeur intermédiaire même si un chemin direct sur le service SMDS est possible.

Il est envisagé que le service évolue pour fournir une interconnexion plus publique, permettant aux machines directement connectées au service SMDS de communiquer sans routeur intermédiaire. Cependant, les questions soulevées par une grande interconnexion publique, telles que l’échelonnabilité de la résolution d’adresse ou la propagation des mises à jour des routages, sortent du domaine d’application du présent document. Il est prévu que d’autres RFC traitent ces questions à l’avenir.

Ci-après figure une liste d’exigences pour une configuration de LIS :

o Tous les membres ont le même numéro de réseau/sous-réseau IP.

o Toutes les stations au sein d’un LIS sont en accès direct sur SMDS.

o Toutes les stations extérieures au LIS sont en accès via un routeur.

o Pour chaque LIS a été configurée une seule adresse de groupe SMDS qui identifie tous les membres du LIS. Tout paquet transmis avec cette adresse est livré par le service SMDS à tous les membres du LIS.

La liste suivante identifie un ensemble de paramètres spécifiques du service SMDS qui DOIVENT être mis en œuvre dans chaque station IP qui va se connecter au service SMDS. Les valeurs des paramètres seront déterminées au moment de l’abonnement à SMDS et seront différentes pour chaque LIS. Et donc, ces paramètres DOIVENT être configurables par l’usager.

o Adresse de matériel SMDS (smds$ha). C’est l’adresse SMDS individuelle de la station IP, telle que déterminée au moment de l’abonnement. Chaque hôte DOIT être configuré pour accepter les datagrammes destinés à cette adresse.

o Adresse de groupe de LIS SMDS (smds$lis-ga). C’est l’adresse de groupe SMDS qui a été configurée au moment de l’abonnement pour identifier les interfaces réseau d’abonné (SNI, Subscriber Network Interfaces) SMDS de tous les membres du LIS connectés au service SMDS. Tous les membres du LIS DOIVENT être prêts à accepter les datagrammes adressés à smds$lis-ga.

o Adresse de demande ARP SMDS (smds$arp-req). C’est l’adresse SMDS (individuelle ou de groupe) à laquelle les demandes ARP sont à envoyer. Dans la configuration de LIS initiale, cette valeur est réglée à smds$lis-ga. Il est concevable que dans d’autres configurations, cette valeur soit réglée à une adresse autre que smds$lis-ga (voir la section sur la résolution d’adresse).

Il est RECOMMANDÉ que les routeurs qui fournissent la fonctionnalité de LIS sur le service SMDS aient aussi la capacité d’interconnecter des LIS différents. Les routeurs qui souhaitent fournir l’interconnexion de LIS différents DOIVENT être capables de prendre en charge plusieurs ensembles de ces paramètres (un ensemble pour chaque LIS connecté) et être capables d’associer chaque ensemble de paramètres à un numéro de réseau/sous-réseau IP spécifique. De plus, il est RECOMMANDÉ qu’un routeur soit capable de fournir cette prise en charge de LIS multiple avec une seule interface physique SMDS qui peut avoir une ou plusieurs adresses SMDS individuelles.

La liste suivante identifie les paramètres de LIS spécifiques qui DOIVENT être configurés dans le réseau qui prend en charge le service SMDS. Pour chaque LIS, l’administrateur de réseau IP DOIT demander la configuration de ces paramètres au moment de l’abonnement. L’administrateur de chaque LIS DOIT mettre à jour ces paramètres chaque fois qu’une station s’ajoute au LIS.

o Adresse de groupe LIS SMDS (smds$lis-ga). Une adresse de groupe SMDS DOIT être configurée au moment de l’abonnement pour identifier les interfaces réseau d’abonné (SNI) SMDS de tous les membres du LIS connectés au service SMDS.

o Tableaux de filtrage d’adresse SMDS (de source et de destination). L’utilisation des tableaux de filtrage SMDS n’est pas nécessaire pour le fonctionnement d’IP sur le service SMDS. Si les tableaux de filtrage SMDS doivent être utilisés, les tableaux de source et de destination pour chaque SNI DOIVENT être configurés pour permettre, au minimum, à la fois la communication directe entre tous les hôtes dans le même LIS et l’utilisation de l’adresse de groupe de LIS SMDS.

Format de paquet

Le service DEVRA être encapsulé au sein des couches de liaison des données LLC de IEEE 802.2 et de protocole d’accès de sous-réseau (SNAP, Sub-Network Access Protocol) IEEE 802.1A [10] et le niveau 3 de SIP. Le SNAP DOIT être utilisé avec un code d’identifiant univoque d’organisation indiquant que l’en-tête SNAP contient le code EtherType figurant sur la liste des Numéros alloués [11] (voir la Figure 2). Noter que les valeurs spécifiées dans le présent document suivent les conventions de l’Internet : les champs de plusieurs octets sont décrits en ordre gros-boutien et les bits au sein des octets sont décrits avec celui de plus fort poids en premier [11].

Figure 2. Encapsulation de liaison des données

o La valeur de HLPI dans l’en-tête SIP L3 est 1.

o La longueur totale de l’en-tête LLC et de l’en-tête SNAP est de 8 octets.

o La valeur de DSAP et SSAP dans l’en-tête LLC est de 170 (décimal), AA (Internet hexadécimal).

o La valeur de Ctrl (contrôle) dans l’en-tête LLC est de 3 (indique des informations non numérotées de type trois).

o Le Code d’organisation dans l’en-tête SNAP est zéro (000000 en Internet hexadécimal).

o L’EtherType pour IP est 2048 (en décimal), 0800 (en Internet hexadécimal). L’EtherType pour ARP est 2054 (en décimal), 0806 (en Internet hexadécimal).

On utilise exclusivement la communication d’informations non numérotées (UI, Unnumbered Information) de type un LLC de la norme IEEE 802.2 (qui doit être mise en œuvre par toute station conforme à IEEE 802.2). Le champ identifiant de protocole de couche supérieure (HLPI, Higher Layer Protocol Id) dans l’en-tête SIP L3_PDU DOIT être réglé à la valeur d’identifiant de protocole allouée par IEEE 802.6 pour LLC (décimal 1) [8]. Toutes les trames DOIVENT être transmises dans le format d’informations non numérotées de type un LLC de la norme IEEE 802.2, avec les champs DSAP et SSAP de l’en-tête IEEE 802.2 réglé à la valeur SAP globale allouée pour SNAP (décimal 170) [10]. Le code Org (Code d’identifiant unique d’organisation) de 24 bits dans le SNAP DOIT être réglé à la valeur de zéro, et les 16 bits restants à la valeur EtherType tirée des Numéros alloués [11] (2048 pour IP, 2054 pour ARP).

L’encapsulation de liaison des données pour les paquets IP est montrée à la Figure 3 et pour ARP à la Figure 4. Toutes les valeurs données sont en format hexadécimal Internet.

Figure 3. Encapsulation et valeurs de liaison de données IP

Figure 4. Encapsulation et valeurs de liaison de données ARP

Résolution d’adresse

La transposition dynamique des adresses Internet de 32 bits en adresses SMDS DEVRA être effectuée via la procédure de découverte dynamique du protocole de résolution d’adresse (ARP, Address Resolution Protocol) [2].

Les adresses Internet sont allouées indépendamment des adresses SMDS. Chaque mise en œuvre d’hôte DOIT connaître sa propre adresse Internet et sa propre adresse SMDS et répondre aux demandes de résolution d’adresse de façon appropriée. Les hôtes DOIVENT aussi utiliser ARP pour transposer les adresses Internet en adresses SMDS lorsque nécessaire.

Le protocole ARP possède plusieurs champs qui mettent en paramètres son utilisation dans des contextes spécifiques [2]. Ces champs sont :

ar$hrd 16 – bits Code de type de matériel
ar$pro 16 – bits Code de type de protocole
ar$hln 8 – bits Octets dans chaque adresse de matériel
ar$pln 8 – bits Octets dans chaque adresse de protocole
ar$op 16 – bits Code de fonctionnement

o Le code de type de matériel alloué aux adresses SMDS est 14 (décimal), 0E (hexadécimal Internet) [11].
o Le code de type de protocole pour IP est 2048 (décimal), 0800 (hexadécimal Internet) [11].
o La longueur d’adresse de matériel pour SMDS est 8.
o La longueur d’adresse de protocole pour IP est 4.
o Le code de fonctionnement est 1 pour la demande et 2 pour la réponse.

Les adresses de matériel SMDS dans les paquets ARP (ar$sha, ar$tha) DOIVENT être portées dans le format d’adresse natif SMDS, avec le bit de plus fort poids du sous-champ Type d’adresse comme bit d’ordre le plus élevé du premier octet. Bien que ce soit en dehors du domaine d’application du présent document, il est RECOMMANDÉ que les adresses SMDS soient représentées dans ce format dans tous les protocoles Internet de couche supérieure (par exemple, SNMP).

Traditionnellement, les demandes ARP sont diffusées à toutes les stations directement connectées. Pour le service SMDS, le paquet de demande ARP est transmis à l’adresse de matériel smds$arp-req. Dans la configuration de LIS, l’adresse smds$arp-req est réglée à smds$lis-ga, (l’adresse de groupe SMDS qui identifie tous les membres du LIS). On peut concevoir qu’à plus grande échelle, dans une configuration publique, l’adresse smds$arp-req serait configurée à l’adresse de serveurs ARP au lieu de l’adresse de groupe qui identifie le LIS tout entier.

Adresse de diffusion IP

Il n’existe pas de dispositif permettant de mener à son terme l’adressage matériel en diffusion sur le service SMDS. Comme exposé au paragraphe "Configuration de sous-réseau logique IP", une adresse de groupe SMDS (smds$lis-ga) DEVRA être configurée pour inclure toutes les stations dans le même LIS. L’adresse Internet de diffusion (l’adresse sur ce réseau avec une partie hôte toute en uns binaires) DOIT être transposée en smds$lis-ga (voir aussi [12]).

Prise en charge de la diffusion groupée IP

Une méthode de prise en charge de la diffusion groupée sur IP est spécifiée dans [13]. Il serait souhaitable d’utiliser pleinement les capacités d’adresse de groupe SMDS pour la prise en charge de la diffusion de groupe sur IP. Cependant, la méthode de [13] exige une interface de service réseau qui fournisse une capacité de diffusion de groupe pour donner l’accès dynamique aux opérations d’interface de service de réseau locales :

o JoinLocalGroup (adresse de groupe)
o LeaveLocalGroup (adresse de groupe)

La facilité d’adresse de groupe SMDS ne prend pas actuellement en charge l’adhésion et le retrait dynamique des listes d’adresse de groupe. Donc, il est RECOMMANDÉ que dans la configuration de LIS, si la diffusion groupée sur IP doit être prise en charge, la méthode de diffusion groupée sur IP décrite pour les supports de diffusion pure, tels que Ethernet expérimental, soit utilisée. Pour cette méthode, toutes les adresses IP en diffusion de groupe sont transposées en la même adresse SMDS dans laquelle l’adresse Internet de diffusion est transposée pour un LIS donné. Et donc, toutes les adresses IP en diffusion de groupe sont transposées en smds$lis-ga. Le filtrage des paquets en diffusion de groupe DOIT être effectué chez l’hôte de destination.

Formats d’en-queue

Certaines versions de BSD Unix 4.x utilisent une méthode d’encapsulation différente afin d’obtenir de meilleures performances réseau avec l’architecture de mémoire virtuelle VAX. Les en-queues NE DEVRONT PAS être utilisées sur le service SMDS.

Ordre des octets

Comme décrit dans l’Appendice B de la spécification du protocole Internet [1], le datagramme IP est transmis sur le service SMDS comme des séries d’octets de 8 bits. L’ordre d’octet du datagramme IP doit être transposé directement dans l’ordre des octets SMDS natif.

Détails de la sous-couche MAC

Taille de paquet

Le service SMDS définit une taille maximum de données de service de 9 188 octets d’information . Cela laisse 9 180 octets pour les données d’utilisateur après la prise en compte de l’en-tête LLC/SNAP. Donc, la MTU pour les stations IP fonctionnant sur un réseau qui prend en charge le service SMDS DEVRA être de 9 180 octets.

Il n’y a pas de contrainte de taille minimum de paquet définie pour le service SMDS.

Autres questions de sous-couche MAC

L’exigence du service SMDS est que le format d’adresse d’administration publique de 60 bits plus un champ de type de 4 bits DEVRAA être utilisé dans les deux champs d’adresse de source et de destination de la L3_PDU de SIP [3].

Précisions sur IEEE 802.2

Bien que cela ne soit pas nécessaire pour la prise en charge de IP et de ARP, toutes les mises en œuvre DOIVENT prendre en charge le service de classe I de la norme IEEE 802.2 afin d’être conforme à IEEE 802.2. Certaines des fonctions ne sont pas directement en relation avec la prise en charge du SAP SNAP (par exemple, répondre aux commandes XID et TEST dirigées sur les adresses nulles ou globales), mais font partie d’une mise en œuvre générale de LLC. Les documents [4] et [5] décrivent tous deux les fonctionnalités minimum nécessaires pour une station conforme. Les développeurs devraient aussi consulter la norme IEEE 802.2 [14] pour des précisions.

Références

1. J. Postel, "Protocole Internet", RFC 791, USC/Information Sciences Institute, septembre 1981.

2. D. Plummer, "Protocole de résolution des adresses Ethernet - ou – Conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur matériel Ethernet", RFC 826, MIT, novembre 1982.

3. "Generic Systems Requirements in support of Switched Multi-megabit Data Service", Technical Advisory TA-TSY-000772, Bellcore Technical Advisory, Issue 3, octobre 1989.

4. J. Postel et J. Reynolds, "Norme pour la transmission des datagrammes IP sur des réseaux IEEE 802", RFC 1042, USC/Information Sciences Institute, février 1988.

5. D. Katz, "Proposition de norme pour la transmission de datagrammes IP sur des réseaux FDDI", RFC 1188, Merit/NSFNET, octobre 1990.

6. F. Dix, M. Kelly et R. Klessig, "Accès à une offre de service de données public commuté à plusieurs Mégabits", ACM SIGCOMM CCR, juillet 1990.

7. C. Hemrick et L. Lang, "Introduction to Switched Multi-megabit Data Service (SMDS), an Early Broadband Service", publication en cours dans Proceedings of the XIII International Switching Symposium (ISS 90), 27 mai 1990 – 1 juin 1990.

8. Institute of Electrical & Electronic Engineers, Inc. IEEE Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN) Standard", décembre 1990.

9. IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.

10. IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.

11. J. Reynolds et J. Postel, "Numéros alloués", RFC 1060, USC/Information Sciences Institute, mars 1990.

12. R. Braden et J. Postel, "Exigences pour les passerelles Internet", RFC 1009, USC/Information Sciences Institute, juin 1987.

13. S. Deering, "Extensions d’hôte pour la diffusion groupée IP", RFC 1112, Stanford University, août 1989.

14. IEEE,"ANSI/IEEE Std 802.2-1985, ISO Draft International Standard 8802/2", IEEE, New York, New York, 1985.

Considérations pour la sécurité

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

Adresse des auteurs