Encapsulations de paquet pour le protocole général de gestion de commutateur (GSMP) pour le mode de transfert asynchrone (ATM), Ethernet et le protocole de contrôle de transmission (TCP)

Statut de ce mémoire

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et nécessite des discussions et suggestions pour son amélioration. Veuillez vous référer à l'édition courante des "Normes officielles de protocole de l’Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de cette note n’est soumise à aucune restriction.

Copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé

Le présent mémoire spécifie l’encapsulation des paquets du protocole général de gestion de commutateur (GSMP, General Switch Management Protocol) en mode de transfert asynchrone (ATM, Asynchronous Transfer Mode) en Ethernet et en protocole de contrôle de transmission (TCP, Transmission Control Protocol).

Spécification des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119].

1. Introduction

Les messages GSMP sont définis dans la [RFC3292] et PEUVENT être encapsulés dans plusieurs protocoles différents pour le transport. Le présent mémoire spécifie leur encapsulation dans ATM AAL-5, dans Ethernet ou dans TCP. D’autres encapsulations pourront être définies dans de futures spécifications.

2. Encapsulation ATM

Les paquets GSMP sont de longueur variable et pour une couche de liaison de données ATM elles sont encapsulées directement dans une PDU CPCS de couche AAL-5 [I.363], [I.363.5] avec un en-tête LLC/SNAP comme illustré ci-dessous :

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| LLC (0xAA-AA-03) | |

+---------------+---------------+---------------+ +

| SNAP (0x00-00-00-88-0C) |

+---------------+---------------+---------------+---------------+

| |

~ Message GSMP ~

| |

+---------------+---------------+---------------+---------------+

| Bourrage (0 - 47 octets) |

+---------------+---------------+---------------+---------------+

| |

+ En-queue de PDU CPCS AAL-5 (8 octets) +

| |

+---------------+---------------+---------------+---------------+

(La convention dans la documentation des protocoles de l’Internet [RFC3232] est d’exprimer les nombres en décimal. Les nombres en format hexadécimal sont spécifiés en les préfaçant avec les caractères "0x". Les nombres en format binaire sont spécifiés en les préfaçant avec les caractères "0b". Les données sont présentées dans l’ordre "gros boutien", c’est-à-dire que les champs sont décrits de gauche à droite, avec l’octet de poids fort à gauche et l’octet de moindre poids sur la droite. Chaque fois qu’un diagramme montre un groupe d’octets, l’ordre de transmission de ces octets est l’ordre normal dans lequel ils sont lus en français. Chaque fois qu’un octet représente une quantité numérique, le bit le plus à gauche dans le diagramme est le bit de poids fort. C’est-à-dire que le bit marqué 0 est le bit de poids fort. De même, chaque fois qu’un champ multi octets représente une quantité numérique, le bit de gauche du champ complet est le bit de poids fort. Lorsque une quantité multi octets est transmise, l’octet de poids fort est transmise en premier. C’est la même convention de codage qu’utilisée dans la couche ATM [I.361] et AAL-5 [I.363], [I.363.5].)

L’en-tête LLC/SNAP contient les octets : 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. (0x880C est l’Ethertype alloué pour GSMP.)

L’unité de transmission maximum (MTU) du champ Message GSMP est 1492 octets.

Le canal virtuel sur lequel une session GSMP est établie entre un contrôleur et le commutateur qu’il contrôle est appelé le canal de contrôle GSMP. Le VPI et le VCI par défaut du canal de contrôle GSMP pour les messages GSMP encapsulés dans la LLC/SNAP sur une couche de liaison de données ATM est :

VPI = 0

VCI = 15.

Le canal de contrôle GSMP PEUT être changé en utilisant la MIB GSMP.

3. Encapsulation Ethernet

Les paquets GSMP PEUVENT être encapsulés sur une liaison de données Ethernet comme illustré ci-dessous :

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Adresse de destination |

| +---------------+---------------+

| | |

+---------------+---------------+ |

| Adresse de source |

+---------------+---------------+---------------+---------------+

| Ethertype (0x88-0C) | |

+---------------+---------------+ |

| |

~ Message GSMP ~

| |

+---------------+---------------+---------------+---------------+

| Instance d’envoyeur |

+---------------+---------------+---------------+---------------+

| Instance de receveur |

+---------------+---------------+---------------+---------------+

| Bourrage |

+---------------+---------------+---------------+---------------+

| Séquence de vérification de trame |

+---------------+---------------+---------------+---------------+

Adresse de destination

Pour le message SYN du protocole d’adjacence, l’adresse de destination est l’adresse de diffusion 0xFFFFFFFFFFFF. (Autrement, il est aussi valide de configurer le nœud avec l’adresse MAC d’envoi individuel de 48 bits de l’IEEE de la destination. Dans ce cas, l’adresse de destination d’envoi individuel configurée est utilisée dans le message SYN.) Pour tous les autres messages, l’adresse de destination est l’adresse d’envoi individuel de 48 bits de l’IEEE.

Adresse MAC de la destination. Cette adresse peut être découverte à partir du champ Adresse de source des messages reçus durant la synchronisation du protocole d’adjacence.

Adresse de source

Pour tous les messages, l’adresse de source est l’adresse MAC IEEE de 48 bits de l’envoyeur.

Ethertype

L’Ethertype alloué pour GSMP est 0x880C.

Message GSMP

L’unité maximum de transmission (MTU) du champ Message GSMP est 1492 octets.

Instance d’envoyeur

C’est le numéro d’instance d’envoyeur pour la liaison, obtenu du protocole d’adjacence. Ce champ est déjà présent dans le message de protocole d’adjacence. Il est ajouté à tout les messages de non adjacence GSMP dans l’encapsulation Ethernet pour offrir une protection supplémentaire contre l'introduction d’un état corrompu.

Instance de receveur

Le numéro d’instance de receveur est ce que l’envoyeur croit être le numéro d’instance actuel pour la liaison, alloué par l’entité à l’extrémité distante de la liaison. Ce champ est déjà présent dans le message de protocole d’adjacence. Il est ajouté à tous les messages GSMP de non adjacence dans l’encapsulation Ethernet pour offrir une protection supplémentaire contre l’introduction d’un état corrompu.

Bourrage

Après l’établissement de l’adjacence, la longueur minimum du champ de données d’un paquet Ethernet est de 46 octets. Si nécessaire, le bourrage devrait être ajouté afin qu’il satisfasse aux exigences de taille minimum de trame Ethernet. Ce bourrage devrait être d’octets à zéro et n’est pas considéré comme faisant partie du message GSMP.

Séquence de vérification de trame

La séquence de vérification de trame (FCS, Frame Check Sequence) est définie dans [IEEE802.3] comme suit :

Note : Ce paragraphe n’est inclus qu’à des fins d’information historique. La référence normative se trouve dans la norme [IEEE802.3].

"Un contrôle de redondance cyclique (CRC, cyclic redundancy check) est produit par les algorithmes d’émission et de réception pour générer une valeur de CRC pour le champ FCS. Le champ Séquence de vérification de trame (FCS) contient une valeur de 4 octets (32 bits) de contrôle de redondance cyclique (CRC). Cette valeur est calculée comme une fonction du contenu de l’adresse de source, de l’adresse de destination, de la longueur, des données de LLC et du bourrage (c’est-à-dire, tous les champs excepté le préambule, SFD, FCS et extension). Le codage est défini par le polynôme générateur suivant.

G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^ 7+x^5+x^4+x^2+x^1."

On trouvera la procédure de calcul du CRC dans [IEEE802.3].

Après que le protocole d’adjacence a réalisé la synchronisation, pour chaque message GSMP reçu avec une encapsulation Ethernet, le receveur doit vérifier l’adresse de source à partir de l’en-tête MAC Ethernet, l’instance d’envoyeur, et l’instance de receveur. Le message GSMP entrant doit être éliminé si l’instance d’envoyeur et l’adresse de source ne correspondent pas aux valeurs d’instance d’envoyeur et de nom d’envoyeur mémorisées par l’opération "Update Peer Verifier" du protocole d’adjacence GSMP. Le message GSMP entrant doit aussi être éliminé si il arrive sur tout accès autre que celui sur lequel le protocole d’adjacence a réalisé la synchronisation. De plus, le message entrant doit aussi être éliminé si le champ Instance de receveur ne correspond pas à la valeur courante pour l’instance d’envoyeur du protocole d’adjacence GSMP.

4. Encapsulation TCP/IP

Lorsque les messages GSMP sont transportés sur un réseau IP, ils DOIVENT être transportés en utilisant l’encapsulation TCP. TCP donne un transport fiable, un contrôle de flux réseau, et un contrôle de flux de système d’extrémité convenable pour les réseaux qui peuvent avoir de fortes pertes et des délais variables ou imprévisibles.

Pour les encapsulations TCP de messages GSMP, le contrôleur applique le code client et le commutateur applique le code du serveur. À l’initialisation, le serveur écoute sur le numéro d’accès TCP de GSMP : 6068. Le contrôleur établit une connexion TCP avec chaque commutateur qu’il gère. Le commutateur sous contrôle DOIT être un serveur multi connexions (PORT 6068) pour permettre la création de plusieurs sessions de contrôle à partir de N instances de contrôleur GSPM. Les messages de protocole d’adjacence, qui sont utilisés pour synchroniser le contrôleur et le commutateur et entretenir la prise de contact, sont envoyés par le contrôleur au commutateur après l’établissement de la connexion TCP. Les messages GSMP autres que les messages de protocole d’adjacence NE DOIVENT PAS être envoyés tant que le protocole d’adjacence n’a pas réalisé la synchronisation. Le flux réel de messages GSMP va se produire sur d’autres accès.

4.1 Formats de message

Les messages GSMP sont envoyés sur une connexion TCP. Un message GSMP n’est traité qu’après avoir été reçu en entier. Un champ d’en-tête TLV de quatre octets est ajouté au message GSMP pour assurer la délimitation des messages GSMP dans le flux TCP.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type (0x88-0C) | Longueur |

|---------------+---------------+---------------+---------------+

| |

~ Message GSMP ~

| |

+---------------+---------------+---------------+---------------+

Type

Ce champ de 2 octets indique le code de type du message qui suit. Le code de type pour le message GSMP est 0x88-0C (c’est-à-dire, le même que l'Ethertype de GSMP).

Longueur

Cet entier non signé de deux octets indique la longueur totale du seul message GSMP. Il n’inclut pas l’en-tête TLV de quatre octets.

4.2 Considérations sur la sécurité TCP/IP

Lorsque GSMPv3 est mis en œuvre dans les réseaux IP, des dispositions pour la sécurité entre le contrôleur et le client DOIVENT être disponibles et DOIVENT être fournies par la sécurité IP [RFC2401]. Dans ce cas, l’encapsulation de charge utile de sécurité (ESP, Encapsulation Security Payload) IPsec DOIT être utilisée pour assurer la protection de l’intégrité et de la confidentialité.

5. Considérations sur la sécurité

La sécurité du canal de contrôle TCP/IP de GSMP a été traitée au paragraphe 4.2. Pour toute utilisation de GSMP sur un réseau IP il est EXIGÉ que GSMP fonctionne sur TCP/IP en utilisant les considérations de sécurité exposées au paragraphe 4.2. La sécurité utilisant les encapsulations ATM et Ethernet PEUT être fournie à la couche liaison. Un exposé sur ces méthodes sort du domaine d’application de la présente spécification. Pour un fonctionnement sûr sur tout support, l’encapsulation IP avec IPsec DEVRAIT être utilisée.

Références

[I.361] Recommandation UIT-T I.361, "Spécification de la couche ATM en RNIS-LB", Union Internationale des Télécommunications, février 1999.

[I.363] Recommandation UIT-T I.363, "Spécification de la couche d’adaptation ATM (AAL) en RNIS-LB", Union Internationale des Télécommunications, mars 1993.

[I.363.5] Recommandation UIT-T I.363.5, "Spécification de la couche d’adaptation ATM en RNIS-LB : AAL type 5", Union Internationale des Télécommunications, août 1996.

[IEEE802.3] Std IEEE 802.3, édition 1998, "Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2401] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voir RFC4301)

[RFC3232] J. Reynolds, "Numéros alloués : la RFC 1700 est remplacée par une base de données en ligne", janvier  2002.

[RFC3292] A. Doria et autres, "Protocole général de gestion de commutateur (GSMP) v3", juin 2002. (P.S.)

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.