Spécifications du service multicast ipv6 sur renater
Yüklə 93,96 Kb.
|
- Bu səhifədəki naviqasiya:
- Service rendu à lusager
- Les portées de diffusion en IPv6
- Mise en oeuvre du service multicast IPv6 dans RENATER
- Configurations relatives à la gestion de la portée des diffusions (scoping)
- Interdomaine multicast (service ASM)
- Configuration des points de rendez-vous
- Filtrage des PIM registers
- Apprentissage des RP de RENATER dans les réseaux de collecte et les sites
- Note sur lutilisation de SAP (Session Announcement Protocol - RFC 2974)
- Allocation dadresses multicast aux usagers de RENATER (ASM)
- Connexions multicast IPv6
- Sites et réseaux de collecte
- SFINX Un VLAN dédié sera configuré pour permettre aux opérateurs de séchanger du trafic IPv6 multicast. Testbed-RENATER-4
- Schéma récapitulatif Multi-homing
- Local-preferences Les local-preferences BGP ne sont pas utilisées pour laddress-family IPv6 multicast dans un premier temps. Utilisation de routes statiques multicast
- Interaction avec lIGP (IS-IS TE)
- Interaction avec le multicast IPv4 (ASM)
- Supervision du routage multicast (BGP4+...)
- Supervision des arbres de diffusion multicast (PIM-SMv2...)
- Supervision des flux multicast
- Etat du déploiement (le 3 mai 2006)
| Specs M6R4 Spécifications du service multicast IPv6 sur RENATER Sommaire Evolutions du document 3 Service rendu à l'usager 4 Les portées de diffusion en IPv6 4 Mise en oeuvre du service multicast IPv6 dans RENATER 5 PIM-SMv2 5 MLD 5
Configurations relatives à la gestion de la portée des diffusions (scoping) 5 Interdomaine multicast (service ASM) 6 Configuration des points de rendez-vous 7 RP - Portée globale 7 RP - Portée RENATER 8 Filtrage des PIM registers 8 Redondance de RP 9 Apprentissage des RP de RENATER dans les réseaux de collecte et les sites 9 Note sur l'utilisation de SAP (Session Announcement Protocol - RFC 2974) 9 Allocation d'adresses multicast aux usagers de RENATER (ASM) 10 Connexions multicast IPv6 10 Tunnels multicast IPv6 10 Sites et réseaux de collecte 10 GEANT 11
SFINX 11 Testbed-RENATER-4 11 Autres réseaux 11 M6Bone 11 Migration broker 11 Routage 11 Filtrages en entrée 12 Filtrages en sortie 12 Schéma récapitulatif 13 Multi-homing 13 Local-preferences 13 Utilisation de routes statiques multicast 14 Interaction avec l'IGP (IS-IS TE) 14 Interaction avec le multicast IPv4 (ASM) 14 Supervision 14 Supervision du routage multicast (BGP4+...) 14 Supervision des arbres de diffusion multicast (PIM-SMv2...) 15 Looking-glass 16 Supervision des flux multicast 16 Etat du déploiement (le 3 mai 2006) 17 Fait 17 Planifié 17 Futur 18 Matériel utilisé 18 SAGA 18 Glossaire 18 Références 19 Evolutions du documentNotons que ce document sera mis à jour en continu, en fonction des évolutions du service multicast IPv6.
Service rendu à l'usagerIl existe 2 modèles de diffusion multicast, indépendants de la version du protocole IP :
L'usager pourra, en fonction des applications qu'il souhaite déployer, avoir besoin de mettre en oeuvre le modèle ASM ou SSM (ou les deux). Ceci aura un impact sur les protocoles à mettre en œuvre et les procédures de supervision et de gestion du réseau. Le design décrit dans ce document permet de déployer un service IPv6 global, incluant par défaut une offre multicast. Les réseaux connectés en direct sur RENATER pourront activer le multicast sans faire de demande, juste en activant le protocole PIM. Les services ASM et SSM sont offerts par défaut, un service de RP embarqué (embedded-RP) est aussi offert par défaut, des préfixes multicast étant automatiquement alloués aux sites. Les portées de diffusion en IPv6L'adresse multicast est définie comme il suit: L 0 - reserved 2 - link-local scope 4 - admin-local 5 - site-local scope 8 - organization-local scope E - global scope F - reserved Dans RENATER, les portées seront définies de la façon suivante:
Exemple: INSA de Lyon, CEA Saclay
Exemple: Groupement de tous les INSA en France, CEA, CNRS
Mise en oeuvre du service multicast IPv6 dans RENATERPIM-SMv2Le protocole de construction d'arbre de diffusion multicast pour IPv6 est PIM-SMv2. Ce protocole est utilisé aussi bien pour le service ASM que le service SSM. Ce protocole sera déployé sur tous les NR. La commande IOS relative est : ipv6 multicast-routing Cette commande active par défaut PIM sur toutes les interfaces configurées pour IPv6. La commande pour désactiver PIM sur une interface spécifique est : interface XXX no ipv6 pim Pour le support du service ASM, la configuration d'un point de rendez-vous, et l'allocation d'adresses multicast IPv6 aux sites sera nécessaire. Ces aspects sont vus dans le détail dans la suite de ce document. MLDMLD est l'équivalent de IGMPv2 et MLDv2 est l'équivalent de IGMPv3. Ces protocoles permettent la gestion des abonnements entre un routeur et des clients. MLDv2 permet en plus de la gestion des groupes multicast, de spécifier un ensemble de sources. MLDv2 est utilisé pour le modèle SSM. MLD doit être spécifiquement désactivé sur toutes les interfaces du backbone, sauf celles qui sont connectées à des hôtes (stations de supervisions, sondes...) La commande IOS relative est: no ipv6 mld On notera que MLD est par défaut activé sur toutes les interfaces. On notera également la différence avec IPv4, car si MLD peut être désactivé, il n'est pas possible de désactiver IGMP sur une interface si PIM est activé sur l'interface. Configurations relatives à la gestion de la portée des diffusions (scoping)Comme spécifié plus haut, seules les portées supérieures ou égales à A (en hexadécimal) pourront transiter dans le backbone RENATER. La portée A est restreinte au backbone RENATER et à ses usagers.
Par conséquent, sur chaque interface vers les sites RENATER ou les réseaux de collecte, nous filtrerons les portées strictement inférieures à A. La commande relative à configurer sur les interfaces est: ipv6 multicast boundary scope 9 Sur chaque interface vers des réseaux qui ne sont ni des réseaux de collecte, ni des sites RENATER, il faudra filtrer toutes les portées inférieures ou égales à A. La commande relative à configurer sur les interfaces : ipv6 multicast boundary scope 10 A noter:
Interdomaine multicast (service ASM)La question de l'interdomaine pour le service SSM ne se pose pas puisque les arbres multicast sont construits directement des récepteurs à la source avec PIM-SMv2. Le modèle SSM IPv6 ne diffère pas du modèle SSM IPv4. Pour le service ASM, l'interdomaine IPv6 est complètement différent de ce qui est fait pour IPv4. Le protocole MSDP n'existe pas pour IPv6 et ne sera jamais spécifié. La solution pour gérer l'interdomaine ASM IPv6 est "embedded-RP" (RFC 3956). La solution consiste à insérer l'adresse du point de rendez-vous dans l'adresse multicast :
L'adresse d'un RP de type Embedded-RP doit forcément avoir tous les bits de l'Interface Identifier, sauf les 4 bits de poids faible à zéro. Par exemple l'adresse 2001:660:3001:4001::d peut être utilisée pour configurer un Embedded-RP. Embedded-RP permet donc juste d'effectuer le "group-to-RP mapping" (comme BSR, ou auto-RP par exemple). Embedded-RP sera activé sur tous les routeurs de RENATER-4. Il est activé par défaut avec la commande : ipv6 multicast-routing Le modèle change par rapport à IPv4 dans le sens où le point de rendez-vous est fonction de l'adresse multicast utilisée et n'est plus forcément local. Il est fort probable que certains établissements ou réseaux de collecte connectés à RENATER déploient leur propre point de rendez-vous. Néanmoins, il paraît utile dans un premier temps d'offrir un service de point de rendez-vous, pouvant être utilisé par des sites ne pouvant pas déployer ces ressources en interne. Le détail de la configuration des RP est donné dans la section "Configuration des points de rendez-vous". Pour que les sites puissent utiliser les RP déployés sur RENATER, il sera nécessaire d'allouer des préfixes multicast aux sites RENATER faisant la demande de raccordement au service. Ceci est détaillé dans la section "Allocation d'adresses multicast aux usagers de RENATER". Il est à noter qu'à plus long terme, le service de point de rendez-vous pourra disparaître du cœur de RENATER-4, si les sites peuvent gérer ce service eux-mêmes. Configuration des points de rendez-vousLa seule méthode de découverte de RP est Embedded-RP. Tous les RP déployés seront donc du type Embedded-RP. Si les sites peuvent déployer leur propre RP (pour un scope restreint ou pour un scope global), 2 points de rendez-vous seront déployés sur RENATER, l'un sera utilisé pour une portée globale, l'autre pour une portée restreinte a la communauté RENATER. Ces RP seront déployés sur le même routeur C7204, qui n'aura que la fonction de RP (pas de connexions vers les sites, pas de tunnels...). Ainsi en cas d'utilisation anormale des points de Rendez-vous, le réseau n'est aucunement impacté. Ce routeur aura 2 adresses compatibles Embedded-RP configurées sur 2 interfaces de loopback. Ainsi il sera aisé de changer la localisation de chacun des RP s'il devient dans le futur nécessaire d'utiliser 2 équipements différents. Il est nécessaire de prévoir cette possibilité dès le déploiement initial, car cela permet d'éviter de devoir changer les préfixes multicast IPv6 alloués aux sites connectés. Afin de pouvoir allouer des préfixes multicast de taille 96 aux sites RENATER (voir section "Allocation d'adresses multicast aux usagers de RENATER", il sera nécessaire que les adresses utilisées pour les points de rendez-vous configurés dans l'épine dorsale soient de la forme: 2001:660:klmn::y Le préfixe multicast dérivé de ce type d'adresse sera de longueur 80 en suivant la mécanique Embedded-RP décrite dans le RFC 3956 : FF7X:y30:2001:660:klmn::/80 X représente la portée de la diffusion.
RP - Portée globaleCe RP est configuré pour une portée globale (scope E). La commande pour configurer ce RP est: ipv6 pim rp-address @loopback_RP_global rp-global Il faut ensuite définir l'access-list rp-global qui indique les groupes multicast gérés par le RP. ipv6 access-list rp-global permit ipv6 any embedded_global Embedded_global est le préfixe multicast dérivé de l'adresse du RP, suivant la méthode Embedded-RP décrite dans le RFC 3956, et rappelée dans la section "Interdomaine multicast (service ASM)" de ce document. Dans l'exemple utilisé plus haut, si l'adresse du RP est 2001:660:3001::d, le préfixe multicast est FF7E:D30:2001:660:3001::/80. RP - Portée RENATERCe RP est configuré pour la portée RENATER définie précédemment (scope A). La commande pour configurer ce RP est: ipv6 pim rp-address @loopback_RP_renater rp-renater Il faut ensuite définir l'access-list rp-global qui indique les groupes multicast gérés par le RP. ipv6 access-list rp-renater permit ipv6 any embedded_renater Embedded_renater est le préfixe multicast dérivé de l'adresse du RP, suivant la méthode Embedded-RP décrite dans le RFC 3956, et rappelée dans la section "Interdomaine multicast (service ASM)" de ce document. Dans l'exemple utilisé plus haut, si l'adresse du RP est 2001:660:3001::d, le préfixe multicast est FF7A:D40:2001:660:3001::/80. Filtrage des PIM registersPour le RP global, toutes les adresses unicast officielles de l'internet IPv6 sont acceptées pour source des messages PIM registers. Les préfixes à configurer pour les messages PIM registers sont donc les mêmes que ceux qui sont configurés sur les peerings eBGP pour l'IPv6 unicast. Les adresses de type 6to4 seront filtrées pour les PIM registers. Si la demande est exprimée, une étude sera menée pour voir comment le multicast et le 6to4 peuvent cohabiter. Il est à noter qu'en cas d'utilisation d'autres préfixes pour les adresses officielles, il faudra mettre à jour les règles de filtrage. Pour le RP RENATER, seules les sources ayant une adresse dans le préfixe de RENATER (2001:660::/32) pourront envoyer des PIM registers. Les commandes relatives sont : ipv6 pim accept-register list ipv6-registers-accepted ipv6 access-list ipv6-registers-accepted permit ipv6 2001:660::/32 embedded_renater permit ipv6 2001::/16 embedded_global permit ipv6 2003::/16 embedded_global permit ipv6 2A00::/16 embedded_global permit ipv6 2600::/12 embedded_global permit ipv6 3FFE::/16 embedded_global
Redondance de RPIl n'existe pour l'instant pas de méthode standardisée de redondance de RP compatible avec Embedded-RP. Une solution appelée anycast-PIM a commencé a voir le jour mais n'est ni standardisée, ni implémentée. Il sera nécessaire de suivre l'évolution de cette solution pour assurer une redondance du service de RP fourni. Il est à noter toutefois que la méthode Embedded-RP permet très simplement de déployer un RP. Ainsi les sites de la communauté RENATER pourront déployer et utiliser leur propre RP. Ceci devrait limiter l'usage des RP fournis par RENATER. Apprentissage des RP de RENATER dans les réseaux de collecte et les sitesLa technique embedded-RP permet d'éviter d'avoir à annoncer l'existence d'un RP puisque l'adresse du RP est contenue dans l'adresse multicast. Il est néanmoins indispensable que cette technologie soit déployée sur l'ensemble des routeurs du réseau multicast IPv6 (RENATER, Réseaux de collectes, sites et tout autre réseau connecté). Néanmoins il est probable que certains sites ou réseaux de collecte auront des équipements qui ne supportent pas Embedded-RP, cette technologie n'étant standardisée que depuis peu de temps. Pour les réseaux ne disposant pas de cette technologie, il faudra configurer statiquement, sur tous les routeurs, l'adresse des RP de RENATER ainsi que les préfixes multicast correspondants. Ces sites seront vivement encouragés à utiliser Embedded-RP afin de pouvoir participer à des sessions utilisant des RP qui ne sont pas forcément connus. Note sur l'utilisation de SAP (Session Announcement Protocol - RFC 2974)Les annonces SAP sont faites sur l'adresse de groupe FF0X:0:0:0:0:0:2:7FFE. Cette adresse n'est pas compatible avec les RP de type Embedded-RP qui servent des adresses multicast dans le préfixe FF7x::/16. Il ne sera par conséquent pas possible d'utiliser SAP pour annoncer des sessions multicast sur RENATER. D'autres méthodes comme des annonces par emails, pages webs... devront être utilisées. Il est à noter que le protocole SAP ne résiste pas au facteur d'échelle et d'autres systèmes sont en ce moment à l'étude pour permettre un mécanisme plus efficace d'annonce de sessions. Allocation d'adresses multicast aux usagers de RENATER (ASM)Pour permettre aux sites connectés au service multicast IPv6 de RENATER-4 d'utiliser les RP déployés dans le cœur, il sera nécessaire d'allouer à chaque site un préfixe multicast dérivé des 2 préfixes multicast servis par les RP de RENATER (embedded_renater et embedded_global) Les préfixes embedded_renater et embedded_global sont des préfixes de taille 80 (voir section "Configuration des points de rendez-vous"). Pour pouvoir respecter le RFC 3307, qui définit des règles pour l'utilisation du group-ID (32 bits de poids faible de l'adresse multicast), nous allouerons aux sites des préfixes multicast de longueur 96. Les 2 préfixes alloués sont : embedded_renater:site_ID::/96 embedded_global:site_ID::/96
Tunnels multicast IPv6Comme expliqué dans les sections suivantes, des tunnels IPv6 multicast seront parfois utilisés pour connecter des réseaux. Les tunnels pourront être de type :
L'encapsulation sur IPv6 sera privilégiée, puisqu'elle permet de dissocier complètement l'exploitation du service multicast IPv6 de celle d'IPv4. Néanmoins il se peut que pour des raisons de performance ou de support du mode IPv6 over IPv6, une encapsulation sur IPv4 soit choisie. Une étude sera menée avant l'établissement d'un tunnel et le choix d'une encapsulation sur IPv4 devra être justifiée. L'utilisation de GRE est laissée libre. Sites et réseaux de collecteUn routeur sera configuré pour créer des tunnels IPv6 multicast vers les réseaux de collecte ou les sites RENATER faisant une demande de connexion au service. Il s'agira d'un routeur 720x, distinct des points de rendez-vous déployés, afin de pouvoir répartir les charges dues à l'encapsulation, et dues au RP. Notons qu'un routeur du testbed RENATER-4 est déjà configuré pour effectuer cette tâche. Il s'agit d'un CISCO 3640, configuré avec une quinzaine de tunnels. Ces connexions devront être migrées vers RENATER-4. GEANTLe multicast IPv6 est supporté nativement sur GEANT. Le peering sera établi sur la même interface que celle utilisée pour l'unicast IPv6 ou sur une sous-interface dédiée. SFINXUn VLAN dédié sera configuré pour permettre aux opérateurs de s'échanger du trafic IPv6 multicast. Testbed-RENATER-4Un peering sera configuré vers le testbed RENATER, sur la même interface que celle utilisée pour l'unicast. Cette connexion sera utilisée dans un premier temps pour pouvoir migrer les connexions existantes vers RENATER-4. Autres réseauxIl est fort probable que, pendant un certain temps, la plupart des connexions vers l'extérieur se fasse à travers des tunnels. Aujourd'hui les connexions vers d'autres réseaux se font dans le M6Bone (voir section suivante). Il est décidé de garder les connexions en tunnel vers d'autres réseaux sur un équipement du Testbed. M6BoneActuellement, un équipement du testbed accueille les connexions de tous les réseaux qui désirent tester le multicast IPv6. L'interconnexion entre le M6Bone et RENATER-4 sera donc faite à travers le testbed. Migration brokerLe migration broker ne supporte pas encore le multicast IPv6. Mais des études sont en cours chez HEXAGO pour développer ce service. Les sites connectés derrière le tunnel broker qui souhaiteront obtenir une connectivité multicast IPv6 devront établir un tunnel dédié pour le multicast. RoutageLa technologie de routage utilisée sera très similaire à celle mise en oeuvre pour IPv4. Le protocole BGP4+ sera utilisé pour tous les peerings :
L'address-family IPv6 multicast sera utilisée pour les peerings vers les réseaux d'opérateurs (SFINX, GEANT, OpenTransit, TEIN) et pour les peerings iMBGP. Pour la connexion des sites et réseaux de collecte, il sera possible de n'avoir qu'un peering eMBGP unicast si les connexions multicast et unicast se font sur la même interface, ceci dans le but de rendre plus simple le déploiement du multicast IPv6 chez les sites et réseaux de collecte. La table BGP IPv6 unicast sera donc utilisée par les algorithmes de RPF check, ce qui impose la configuration suivante sur tous les routeurs de RENATER : ipv6 rpf use-bgp La politique de routage générale pour le multicast IPv6 sera différente de celle de l'unicast IPv6. Le GIP RENATER expérimente depuis plusieurs années les protocoles et applications mises en jeu, et a déployé des connexions de tests vers divers réseaux, répartis un peu partout dans le monde. Ce réseau de test, appelé le M6Bone, est centralisé dans le testbed de RENATER et offre le transit à tous les réseaux qui veulent se connecter. Afin de ne pas perdre toutes les connexions mises en oeuvre, et pour pallier le manque d'opérateurs de transit supportant le multicast IPv6, le réseau RENATER offrira temporairement le transit entre le M6Bone et certains autres réseaux, comme GEANT. Filtrages en entréeSites et réseaux de collecte Sur les peerings vers les sites RENATER connectés en prise directe et vers les réseaux de collecte, les règles appliquées sont les mêmes pour l'unicast et le multicast. Seuls les préfixes indiqués dans les agréments (dans la plupart des cas un préfixe de taille 48) seront acceptés. GEANT et autres opérateurs Les règles de filtrage des annonces BGP sont les mêmes que celles utilisées pour l'unicast IPv6. Testbed Sur le peering avec le testbed, les règles seront différentes de celles utilisées pour l'unicast. En effet peu d'opérateurs fournissent aujourd'hui un service multicast IPv6, et certains sites se raccordent au M6Bone par des tunnels, en annonçant leur /48. De ce fait il existe des préfixes de taille 48 dans le M6Bone. Afin de ne pas perdre ces sites, les règles permettront d'accepter ces préfixes. Tous les préfixes dans des blocs d'adresses officiels (2001::/16, 2003::/16, 3FFE::/16...), d'une longueur inférieure ou égale à 48 seront acceptés sur ces peerings. Ils seront marqués avec une communauté propre au M6Bone. Filtrages en sortieSites et réseaux de collecte Sur les peerings vers les sites et les réseaux de collecte, une route par défaut sera annoncée. Sur demande, toute la table MBGP pourra être annoncée. Des filtres seront appliqués afin d'agréger tous les préfixes des sites RENATER, et de n'annoncer que le préfixe de RENATER (2001:660::/32). GEANT Le préfixe de RENATER et tous les préfixes du M6Bone (communauté spécifique) seront annoncés. Autres opérateurs Seul le préfixe de RENATER sera annoncé par défaut. L'annonce d'autres préfixes pourra être considérée au cas par cas. Testbed Toute la table MBGP sera annoncée. Des filtres seront appliqués afin d'agréger tous les préfixes des sites RENATER, et de n'annoncer que le préfixe de RENATER (2001:660::/32). Schéma récapitulatif
Multi-homingLe multi-homing n'est pour l'instant pas considéré pour le multicast IPv6. En effet la problématique du multi-homing pour le multicast est compliquée et ne sera prise en compte que lors d'une future version des spécifications. Des solutions pourront être étudiées si des réseaux en font la demande. Local-preferencesLes local-preferences BGP ne sont pas utilisées pour l'address-family IPv6 multicast dans un premier temps. Utilisation de routes statiques multicastIl est possible que certains sites ne puissent pas utiliser MBGP dans un premier temps, si les équipements utilisés n'implémentent pas ce protocole. Cependant l'utilisation de routes statiques multicast ne peut être faite simplement dans RENATER-4 puisqu'il n'est pas possible ensuite de les redistribuer dans la table BGP IPv6 multicast (pas de support de cette fonctionnalité sur équipements CISCO). L'usage de routes statiques sera donc interdit dans un premier temps et des solutions techniques seront mises en oeuvre en fonction des demandes particulières. Ces solutions devront être validées avec le GIP RENATER avant d'être déployées. Interaction avec l'IGP (IS-IS TE)L'IGP utilisé dans RENATER est IS-IS TE. Il ne permet pas de fonctionner en mode multi-topology pour le multicast IPv6. Aussi le déploiement d'une topologie identique pour l'unicast et le multicast IPv6 au sein du backbone RENATER-4 est nécessaire. Ceci signifie qu'entre 2 routeurs configurés avec iMBGP, les routeurs intermédiaires doivent supporter le multicast IPv6. Le phasage proposé en fin de ce document permet de s'affranchir de tout problème lié à l'IGP. Interaction avec le multicast IPv4 (ASM)Un service de passerelle, permettant une interaction presque totale et dynamique entre le multicast ASM IPv4 et IPv6, a été déployé au GIP RENATER. Dans un premier temps, ce service restera géré par le GIP RENATER et sera offert à titre de service expérimental. Ce service sera configuré sur un des 2 gatekeepers H323 connectés sur RENATER-4. Néanmoins les utilisateurs devront être informés de l'existence de ce service et de la manière de l'utiliser. Un document spécifique à ce service sera mis en ligne sur le site web de RENATER. SupervisionSupervision du routage multicast (BGP4+...)Comme pour l'unicast IPv6, il n'est pas encore possible de superviser le routage multicast IPv6 en utilisant SNMP. Nous utiliserons les mêmes applications que celles utilisées pour l'unicast IPv6 en attendant : Scripts perl Cet outil sera adapté pour superviser l'état des peerings BGP IPv6 multicast dans le backbone RENATER (iMBGP), et avec les autres réseaux connectés - opérateurs, sites, réseaux de collecte... (eMBGP). Lorsqu'un peering eMBGP sera anormal (flapping, active...), le réseau connecté sera immédiatement prévenu. Le traitement du problème commencera quand le NOC du réseau impacté répondra.
AS-Path tree sera déployé pour collecter régulièrement l'état de la table IPv6 multicast. Cette table devra être accessible publiquement. Supervision des arbres de diffusion multicast (PIM-SMv2...)MIB Il n'existe pas encore de MIB implémentée permettant de superviser le multicast en IPv6. La standardisation d'une nouvelle version de la MIB PIM est en cours à l'IETF, et intègre le protocole IPv6. Il sera nécessaire de suivre régulièrement l'état de l'implémentation de cette MIB. La supervision du protocole MLD n'est pas utile dans le réseau RENATER puisque ce protocole est désactivé sur toutes les interfaces (sauf celles connectées à des hosts).
Il n'existe pas de support IPv6 pour mtrace. De nouvelles spécifications de mtrace sont envisagées pour IPv4 et pour IPv6. Une implémentation devrait être faite prochainement. Il sera nécessaire de suivre les travaux en cours. Supervision active La supervision active est aujourd'hui la seule manière de superviser les arbres de diffusion multicast. Des outils appropriés existent :DBeacon, SSMping et les sondes QOSmetrics. dbeacon dbeacon est une version améliorée de l'outil Beacon utilisé actuellement pour le multicast IPv4. La différence est que le modèle est distribué : les rapports sont envoyés sur un groupe multicast, et par conséquent chaque client peut afficher une matrice locale. Deux dbeacons seront configurés sur le réseau RENATER (sur la même machine). Chaque dbeacon sera configuré pour superviser chacun des RP mis en oeuvre dans RENATER. Un identifiant de groupe de 32 bits particulier sera utilisé : 800d:beac Les sites et réseaux de collecte connectés au service ASM IPv6 de RENATER devront joindre la matrice dbeacon pour obtenir un support du NOC RENATER, ceci pour faciliter la résolution des problèmes liés au multicast. Les matrices dbeacon devront être publiquement accessibles. Une documentation de l'outil sera écrite et disponible depuis les pages d'accès au service.
SSMPING permet de tester la connectivité SSM d'un site. Un serveur SSMPING doit être installé et peut être interrogé par un client SSMPING. Lorsqu'un serveur SSMPING est installé sur un client dbeacon, les 2 applications de supervision peuvent interagir, permettant de faciliter la résolution des problèmes. Il sera donc demandé aux sites qui veulent disposer du service SSM IPv6 de déployer un serveur SSMPING. Aucun support du NOC-RENATER ne sera fait pour les sites ou réseaux de collecte n'ayant pas déployé de serveur SSMPING. Ce serveur doit être déployé sur une station supportant MLDv2. Si le site ou le réseau de collecte se connecte à la fois aux services SSM et ASM IPv6, alors il lui sera demandé d'installer les 2 applications de supervision sur la même machine.
Les sondes QOSmetrics supportent le multicast IPv6. Les protocoles RTP et RTCP sont supportés. les sondes seront donc configurées pour superviser en permanence le multicast IPv6, en se basant sur des groupes servis par les 2 RP déployés sur RENATER. Des alarmes seront configurées pour détecter le moindre incident. Ces sondes permettront d'isoler l'origine des problèmes multicast IPv6. Looking-glassUn jeu de commande devra être ajouté au looking-glass de RENATER pour prendre en compte les commandes suivantes :
Supervision des flux multicastLe collecteur Netflow v9 déployé par le GIP RENATER sera amélioré pour supporter les flux multicast IPv6 et offrir une présentation adéquate des résultats. Il est à noter que les routeurs de type 124xx ne supportent pas l'export des flux IPv6 à la date de rédaction de ce document. Etat du déploiement (le 3 mai 2006)Fait
Planifié
Futur
Matériel utiliséLes routeurs agissant qui connectent les tunnels et assurent le service de RP seront 2 routeurs 720x équipés d'une carte NPE-G1. L'un de ces équipements est le routeur connectant les DOM actuellement au CIP-B, l'autre est le routeur connectant les DOM à Interxion. Tous les DOM seront migrés sur le routeur 720x Rennes6. Ces 2 routeurs serviront également à offrir le service multicast IPv4 (RP anycast et peerings MSDP) SAGALe service multicast est offert par défaut avec le service unicast IPv6. Il n'est pas nécessaire pour un établissement de faire une demande pour obtenir le service multicast IPv6. Chaque établissement ayant un préfixe unicast IPv6 se verra allouer 2 préfixes multicast IPv6 pour l'utilisation des RP embarqués de RENATER. SAGA doit donc être mis à jour pour y parvenir. Les établissements qui ne pourront pas avoir accès à ce service en natif pourront demander un tunnel à travers l'interface SAGA. Cette demande doit donc être faite par les contacts techniques et administratifs de SAGA, même si le tunnel peut être configuré vers une entité du site indépendante. En terme de routage, eMBGP sera déployé à travers le tunnel et les préfixes acceptés sur le peering eMBGP seront les préfixes alloués à l'établissement. En d'autres termes, l'établissement devra annoncer les mêmes préfixes pour l'unicast et le multicast. GlossaireASM - Any Source Multicast IGP - Interior gateway Protocol IP - Internet Protocol MBGP - Multiprotocol Border Gateway Protocol MLD - Multicast Listener Discovery MP-BGP - Multiprotocol Border Gateway Protocol PIM - Protocol Independant Multicast SAP - Session Announcement Protocol SFINX - Service for Frenc INternet eXchange SSM - Source Specific Multicast RéférencesRFC 2710 - Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Status: PROPOSED STANDARD) RFC 2974 - Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Status: EXPERIMENTAL) RFC 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Obsoletes RFC2373) (Status: PROPOSED STANDARD) RFC 3810 - Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Status: PROPOSED STANDARD) RFC 3956 - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Updates RFC3306) (Status: PROPOSED STANDARD) draft-ietf-pim-sm-v2-new-11 - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Fenner, B. Handley, M. Holbrook, H. Kouvelas, I. October 2004 (Status: PROPOSED STANDARD) IPv6 multicast deployment and configuration guide (CISCO Systems) - http://www.cisco.com Site web du M6Bone - http://www.m6bone.net dbeacon - http://artemis.av.it.pt/~hsantos/dbeacon/ SSMPING - http://www.venaas.no/multicast/ssmping/ Yüklə 93,96 Kb. Dostları ilə paylaş:
|
