Résumé

  • La RFC 9889 est un modèle de réalisation Informationnel : ce n’est ni un mécanisme obligatoire ni une BCP. Elle décrit comment des technologies IP/MPLS actuelles peuvent répondre à des objectifs de connectivité liés aux tranches 5G.
  • Elle distingue le découpage réseau 5G du découpage du réseau de transport. Le S-NSSAI du domaine mobile n’est pas visible dans le transport ; le domaine mobile traduit donc l’intention en identifiant explicite au handoff : VLAN, IP ou label MPLS. Le transport peut ensuite rattacher cet identifiant à une instance L2VPN et/ou L3VPN et à ses contrôles de ressources.
  • Le point délicat est la coordination. Mapping, circuits d’attachement, QoS, instanciation VPN, ordonnancement en PE, traitement du transit, capacité, gestion et OAM doivent rester cohérents malgré les frontières d’orchestration.

La RFC 9543 fournit le cadre IETF plus large des network slices ; la RFC 9889 le resserre vers une réalisation pragmatique fondée sur des briques existantes du fournisseur de services. Elle traite la connectivité entre fonctions réseau dans des edge clouds, des centres de données et des domaines WAN. Elle n’établit ni le déploiement par un opérateur donné, ni le support d’un fournisseur, ni des mesures de latence, perte, disponibilité ou isolement.

La séquence du handoff est structurante. Le domaine mobile détermine d’abord l’intention de tranche, puis la traduit en identifiant de plan de données visible sur le circuit d’attachement. Le domaine de transport rattache cet identifiant à une instance L2VPN ou L3VPN, selon la séparation de service et le modèle de transfert nécessaires. L’orchestration coordonne ensuite QoS et allocation de ressources. Un label peut donc identifier le trafic sans définir, à lui seul, son traitement réel.

L2VPN et L3VPN ne sont pas deux noms pour la même chose. L’instance choisie détermine la séparation logique et l’endroit où s’applique la politique de transfert. La RFC 9889 décrit un contrôle fin des ressources aux bords du fournisseur, là où classification et ordonnancement peuvent être liés au circuit, tandis que le contrôle dans le cœur peut être plus grossier. Une politique PE ne prouve donc pas que des ressources équivalentes sont réservées sur chaque segment de transit.

Le mapping QoS traduit des objectifs entre domaines ; il ne crée pas de capacité. La planification et la gestion de capacité font donc partie de la réalisation. L’OAM peut vérifier continuité, accessibilité, identifiants, état du service et traitement observé, mais le paquet de faits ne fournit aucune mesure de production. L’exploitant doit définir la télémétrie faisant foi et l’escalade en cas d’écart.

La RFC 9889 décrit un seul Network Resource Partition (NRP). L’applicabilité à plusieurs NRP est explicitement hors périmètre. Il ne faut pas en déduire un comportement multi-NRP. De même, la responsabilité entre équipes mobile, transport et orchestration dépend du déploiement et n’est pas fixée par la RFC.

Un dispositif de vérification concret peut faire passer un S-NSSAI connu par un circuit d’attachement de test, relever sa valeur VLAN/IP/MPLS, confirmer le rattachement L2VPN ou L3VPN attendu, inspecter classification et ordonnancement du PE, puis comparer le marquage QoS attendu au traitement observé. Il doit aussi tester un mapping volontairement erroné, un circuit absent et une alarme de capacité. Conserver les résultats OAM aux points edge et cœur, les systèmes responsables, les horodatages et le résultat d’un retour arrière. Ce sont des choix de vérification, pas des exigences de la RFC 9889.

Parcours de décision opérateur : (1) définir l’objectif de tranche sans supposer que le transport voit le S-NSSAI ; (2) choisir et gouverner l’identifiant de handoff ; (3) vérifier circuit et instance VPN ; (4) mapper la QoS et allouer les ressources edge ; (5) évaluer traitement du cœur et preuves de capacité ; (6) exécuter OAM et tests négatifs ; (7) attribuer la responsabilité d’un écart ; (8) approuver, suspendre ou annuler la modification.

Sources