Résumé

  • Le GAL 13 distingue un paquet Generic Associated Channel du trafic normal du plan utilisateur. Dans les règles MPLS-TP exposées par la RFC 5586, il se trouve au bas de la pile, est suivi par l’ACH, n’apparaît qu’une fois et est absent des paquets ordinaires du plan utilisateur.
  • L’enveloppe fonctionne sur des pseudowires, des LSP et des sections sans dépendre du trafic utilisateur, du routage du réseau à commutation de paquets ni de fonctions dynamiques du plan de contrôle. Le Channel Type de l’ACH choisit le contexte enregistré.
  • Le G-ACh ne doit pas transporter de trafic utilisateur, et un récepteur ne doit jamais utiliser le GAL comme instruction pour transmettre le paquet vers un autre nœud.

La valeur opérationnelle tient à la séparation des rôles. L’émetteur produit une forme enregistrée ; le LSR, le LER ou le PE récepteur valide l’enveloppe, le support et la distribution. La RFC 5586 définit l’encapsulation et le traitement des exceptions. Elle ne définit ni négociation de capacités, ni autorisation d’action, ni établissement de LSP, ni fonctionnement de la fonction OAM transportée. Un type enregistré ne prouve donc pas qu’un récepteur précis l’a activé, ni qu’un opérateur a autorisé son emploi.

L’ACH commence par le motif binaire 0001, contient une version et transporte un Channel Type de 16 bits. Après retrait des labels MPLS ou pseudowire, le récepteur doit supprimer le paquet s’il ne peut pas traiter le type indiqué, s’il ne dispose pas d’une indication de support obtenue par un moyen hors périmètre, si un type expérimental est désactivé localement, si le premier quartet de l’ACH n’est pas 0001, ou si la version de l’ACH n’est pas reconnue. Il s’agit de limites de compatibilité et de sûreté, non d’un protocole de négociation.

La RFC 7026 a supprimé les TLV de l’ACH définis par la RFC 5586. Le matériel avait du mal à analyser leurs formats et longueurs variables, et aucun Channel Type assigné ne les utilisait ; un message G-ACh ne doit donc pas être précédé d’un TLV ACH. La RFC 7214 a regroupé les registres auparavant dispersés dans un emplacement IANA commun et a clarifié le registre généralisé des Channel Types, sans modifier les assignations. L’autorité actuelle vient des spécifications évaluées par l’IETF et de la politique d’enregistrement IANA, pas de la seule présence du nombre 13.

Le GAL et l’ACH ne sont ni une authentification ni une autorisation. Ils n’authentifient pas l’émetteur, n’approuvent pas une action de gestion, de signalisation, de protection ou de réparation, n’établissent pas un chemin et n’accordent aucune autorité de transfert. Les exigences de sécurité relèvent de chaque spécification de Channel Type et de la politique de l’opérateur. Les sources ne permettent pas non plus d’établir la couverture des fournisseurs, les volumes de production, l’interopérabilité universelle, l’activation actuelle ou la fréquence des suppressions de paquets mal formés.

Les bénéficiaires sont les opérateurs qui veulent une enveloppe commune de maintenance en bande et les concepteurs qui veulent une limite partagée de parsing et de distribution. Les coûts demeurent : traitement spécial, contrôles de support et de version, suppressions, sécurité propre à l’application, congestion et contraintes d’implémentation. Sans G-ACh, les fonctions de maintenance dépendraient davantage de mécanismes spécifiques aux pseudowires, d’alertes IP ou d’encodages applicatifs fragmentés. Ces options peuvent répondre à un besoin local, mais elles n’offrent pas cette enveloppe MPLS générique.

Sources