Lignes d’accès et vitesses de connexion d’abonnés L2TP

Transfert d’informations sur la ligne d’accès

Dans la topologie de réseau illustrée à la Figure 1, lorsqu’un abonné établit une connexion via le CPE, le DSLAM relaie la session PPPoE de l’abonné au routeur configuré en tant que LAC. Lorsque le routeur a établi la session PPPoE, le LAC initie un tunnel L2TP pour transférer les paquets PPP encapsulés de l’abonné vers le réseau du fournisseur.

Parallèlement à la session PPPoE, une connexion ANCP entre le DSLAM et l’agent ANCP sur le routeur transmet des informations sur la boucle locale de l’abonné ainsi que sur les vitesses de liaison des sessions PPPoE sur la boucle locale. Le DSLAM envoie au routeur des chaînes ACI (Agent Circuit Id) et ARI (Agent Remote ID) qui identifient de manière unique l’interface de réception du DSLAM ; ces informations sont codées dans les messages ANCP Port Up et Port Down en tant que TLV d’identification de la ligne d’accès. Les messages ANCP peuvent également inclure des attributs de ligne tels que les débits de données en amont et en aval minimaux, maximums et réels, dans le TLV Attributs de ligne DSL. Le DSLAM peut également envoyer les attributs de la ligne d’accès dans des balises spécifiques au fournisseur qu’il insère dans les messages PADI et PADR.

Figure 1 : Exemple de topologie de réseau L2TP

AVP des informations sur la ligne d’accès

L2TP prend en charge les AVP répertoriés dans le tableau 1 pour transporter ces informations. Les informations de la ligne d’accès ne sont pas nécessaires pour que la session L2TP soit lancée, et l’établissement de cette session n’est pas retardé en attendant que les valeurs soient envoyées par le nœud d’accès. Le contenu du message ICRQ varie généralement entre les lignes d’accès DSL et les lignes d’accès PON. Les AVP 1, 2, 3 et 6 sont utilisés pour l’identification des lignes d’accès pour les LAN et les PON. Si les informations des PON sont déclarées à l’aide d’AVP DSL, le contenu est le même que pour l’accès DSL.

Les informations de ligne d’accès fournies par les AVP dans les messages ICRQ sont transmises à RADIUS dans les VSA du forum DSL. Il n’est pas utilisé pour déterminer le taux de trafic sur les lignes d’accès des abonnés.

Mises à jour de la vitesse de connexion sur le LAC

Vous pouvez configurer le LAC pour qu’il avertisse le LNS lorsque la vitesse de la connexion de l’abonné change par rapport aux valeurs initialement communiquées au LNS par AVP 24 (vitesse de transmission) et AVP 38 (vitesse de réception) dans les messages ICCN (Incoming-Call-Connected). Lorsqu’il est configuré à cette fin, le LAC informe le LNS qu’il peut envoyer ces mises à jour en incluant l’AVP d’activation de la vitesse de connexion (98) dans le message ICRQ lorsque la session L2TP démarre. L’absence de l’AVP d’activation de la vitesse de connexion (98) dans le message ICRQ indique que le LAC n’envoie pas de mises à jour pendant toute la durée de la session.

Lorsque la vitesse de connexion change, le DSLAM en informe l’agent ANCP. L’agent ANCP informe ensuite le LAC, qui relaie à son tour ces informations au LNS en envoyant un message CSUN (Connect-Speed-Update-Notification) qui inclut les vitesses mises à jour dans un AVP de mise à jour de la vitesse de connexion (97) pour chaque session. Le LAC collecte les mises à jour de la vitesse de connexion et les envoie par lots afin de minimiser à la fois la surcharge de performances sur le LAC et la quantité de trafic générée par ces notifications.

Les vitesses initiales dans les messages ICCN et les vitesses mises à jour dans les messages CSUN sont utilisées par le CoS pour façonner le taux de trafic pour les lignes d’accès des abonnés.

La présence de l’AVP d’activation de la mise à jour de la vitesse de connexion (98) dans le message ICRQ informe également le LNS que le LAC répond s’il reçoit un message Connect-Speed-Update-Request (CSURQ) d’un LNS.

Un LNS tiers peut envoyer un message CSURQ à tout moment pendant la durée de vie d’un tunnel pour demander la vitesse de connexion actuelle d’émission et de réception pour une ou plusieurs sessions L2TP. Le LNS inclut les ID de session distants (par rapport au LNS) dans le message CSURQ. Si le LAC a déjà envoyé l’AVP d’activation de la vitesse de connexion (98) pour les sessions demandées, il répond au CSURQ avec un message CSUN qui inclut l’AVP de mise à jour de la vitesse de connexion (97) pour chaque session. Si aucun changement n’a été apporté aux vitesses de connexion à ce moment-là, le LAC inclut simplement les valeurs de vitesse de connexion initiales qui ont été déclarées dans les AVP 24 et AVP 38.

Lorsque vous activez les mises à jour de la vitesse de connexion globales ou pour un LNS spécifique, le LAC n’envoie pas de messages CSUN, sauf si vous avez également configuré l’instruction tx-connect-speed sur ancp ou service-profile.

Mises à jour de la vitesse de connexion sur le LNS

À partir de la version 17.4R1 de Junos OS, un routeur MX Series configuré en tant que LNS peut traiter les informations de ligne d’accès des abonnés et les mises à jour de vitesse de connexion qu’il reçoit du LAC. Le routeur MX Series ne peut pas envoyer de messages CSURQ pour solliciter des mises à jour du LAC.

Les vitesses initiales dans les messages ICCN et les vitesses mises à jour dans les messages CSUN sont utilisées par le CoS pour façonner le taux de trafic pour les lignes d’accès des abonnés.

Interaction entre configurations globales et par destination

Vous pouvez configurer le LAC pour transférer les informations de la ligne d’accès dans le message ICRQ qu’il envoie au LNS et vous pouvez configurer le LNS pour recevoir et traiter ces informations. Vous pouvez configurer cela globalement pour toutes les destinations (points de terminaison) ou pour une destination spécifique. La configuration par destination vous permet de limiter la transmission à un LNS individuel ou à un ensemble de LNS ou la réception d’un LAC individuel ou d’un ensemble de LAC. Ceci est utile lorsque vous savez que certaines passerelles distantes ne prennent pas en charge cette fonctionnalité ou ont une implémentation incorrecte.

Incluez l’instruction access-line-information à l’un ou aux deux niveaux hiérarchiques suivants sur le LAC ou le LNS, respectivement, pour configurer le LAC afin qu’il transfère les informations de la ligne d’accès dans le message ICRQ qu’il envoie au LNS, ou pour configurer le LNS pour recevoir et traiter ces informations :

• [edit services l2tp]: configure le transfert globalement pour toutes les destinations.

• [edit services l2tp destination ip-address]: configure le transfert pour une destination spécifique.

Pour configurer le LAC pour envoyer des mises à jour de vitesse de connexion ou le LNS pour recevoir et traiter les mises à jour, incluez l’option connection-speed-update avec l’instruction access-line-information au niveau hiérarchique approprié sur le LAC ou le LNS, respectivement.

Les paramètres globaux et par destination interagissent de la manière suivante :

• Informations sur la ligne d’accès : lorsque le transfert par le LAC ou le traitement par le LNS est activé globalement, vous ne pouvez pas désactiver le paramètre global pour une destination spécifique.

• Mises à jour de la vitesse de connexion : lorsque le transfert par le LAC ou le traitement par le LNS est activé globalement, vous pouvez désactiver le paramètre global pour une destination spécifique (LNS ou LAC) en spécifiant access-line-information la destination et en connection-speed-updateomettant .

Méthodes de détermination des valeurs de vitesse communiquées au LNS

Les valeurs déclarées au LNS peuvent être dérivées des manières suivantes :

• Vous pouvez configurer une méthode globalement pour le LAC avec l’instruction tx-connect-speed-method au niveau de la [edit services l2tp] hiérarchie. Vous pouvez spécifier l’une des méthodes suivantes pour déterminer la source des vitesses de connexion :

  Remarque :

  À partir de la version 13.3R1 de Junos OS, la disponibilité et la prise en charge des méthodes varient selon la version de Junos OS, comme décrit dans le Tableau 2. La liste suivante comprend toutes les méthodes historiques ; Certaines méthodes peuvent ne pas être prises en charge dans la version du logiciel que vous utilisez.

  • actual: la vitesse est le débit réel du trafic en aval appliqué au nœud du planificateur de session en fonction de la stratégie de contrôle du trafic local. Seule la vitesse de connexion de transmission est disponible avec cette méthode, de sorte que la vitesse de transmission de réception est déterminée par le schéma de secours. Utilisez la actual méthode lorsque vous avez besoin que la valeur rapportée soit la vitesse en aval appliquée par la stratégie CoS locale. D’autres méthodes peuvent différer de cette valeur imposée.

    La actual méthode n’est prise en charge que lorsque l’instruction effective shaping-rate est incluse au niveau de la [edit chassis] hiérarchie. La vérification de validation CLI échoue si elle est configurée mais que actual le taux de mise en forme effectif n’est pas configuré.

    Aucune vérification de validation n’est effectuée lorsque la VSA Tunnel-Tx-Speed-Method (26-94) est définie, de sorte qu’un message de journal système est généré dans cette situation pour rappeler à l’utilisateur de configurer le taux de mise en forme effectif.

  • ancp: la vitesse est la valeur ajustée en amont et en aval provenant de l’ANCP qui résulte d’une correction en pourcentage configurée des valeurs ANCP réelles. L’ajustement est appliqué par DSL pour tenir compte des différences d’encapsulation ATM entre le BNG et la boucle d’accès, ainsi que de la surcharge de transport de couche 1. Le taux initial envoyé au LNS est la valeur ANCP déclarée au moment de l’envoi de l’ICCN. Toutes les modifications ultérieures sont envoyées sous forme de mises à jour au LNS dans le message CSUN.

  • none: cette option empêche le LAC d’envoyer AVP 24 ou AVP 38 dans le message ICCN ; par conséquent, aucun message CSUN n’est envoyé non plus. Le LNS doit établir sa propre politique en amont et en aval en l’absence de ces valeurs. Cette option remplace les VSA RADIUS de Juniper Networks, Tx-Connect-Speed (26-162) et Rx-Connect-Speed (26-163), ainsi que toute autre méthode configurée pour la vitesse de connexion.

  • pppoe-ia-tags: la vitesse est dérivée de la valeur envoyée par le DSLAM au LAC dans les balises d’agent intermédiaire (IA) PPPoE (Point-to-Point Protocol over Ethernet). Pour les interfaces Ethernet, la vitesse est une valeur non ajustée ; pour les interfaces ATM, la valeur peut être une valeur ajustée si la balise inclut l’attribut Overhead d’encapsulation (0x90).

    Cette valeur de vitesse est transmise lorsque la session L2TP est établie. Bien que la valeur de la balise PPPoe IA ne change pas au cours d’une session, la vitesse signalée au LAC peut changer. Par exemple, supposons que la méthode configurée est service-profile. Le profil n’est pas activé avant l’envoi de l’ICCN et revient à la balise PPPoE AI, qui est envoyée dans le message ICCN. Lorsque le profil de service est activé ultérieurement, les tarifs du profil de service sont envoyés dans un message de mise à jour (si des mises à jour sont configurées).

  • service-profile: selon la version de Junos OS, il existe deux façons d’utiliser les profils de service pour fournir des vitesses de connexion. Une méthode utilise les vitesses du profil de service uniquement dans les messages CSUN, l’autre méthode dans les messages ICCN.

    • Dans les messages CSUN : la vitesse en aval (Tx) est dérivée du CoS réel appliqué au nœud L3 en fonction de la stratégie locale. La vitesse en amont (Rx) est tirée de la valeur configurée dans le profil de service ; Aucun ajustement n’est apporté à cette valeur.

      Par défaut, les profils de service ne sont pas activés avant l’établissement de la session d’abonné, de sorte que cette méthode revient à une autre méthode pour les valeurs envoyées dans l’ICCN. Lorsque le profil est activé ultérieurement, ces taux sont envoyés au LNS dans un message CSUN, si les mises à jour sont activées.

    • Dans les messages ICCN : à partir de la version 18.1R1 de Junos OS, vous pouvez utiliser un profil de service dynamique pour fournir les vitesses de connexion incluses dans AVP 38 et AVP 24 dans le message ICCN lorsque la session L2TP est négociée. Lors de la connexion de l’abonné, authd détermine si le nom du profil de service transmis dans la VSA d’activation de service de Juniper Networks (26-65) dans le message d’accès-acceptation de RADIUS correspond au nom de profil de service configuré avec l’instruction service-rate-limiter au niveau de la [edit access] hiérarchie. Si les noms correspondent, les vitesses sont dérivées soit des valeurs par défaut dans le profil de service, soit des paramètres passés par le VSA. Pour plus d’informations sur cette méthode, consultez Spécification d’un profil de service limitant le débit pour les vitesses de connexion L2TP .

    La service-profile méthode n’est prise en charge que lorsque l’instruction effective shaping-rate est incluse au niveau de la [edit chassis] hiérarchie. La vérification de validation CLI échoue lorsqu’elle service-profile est configurée, mais que le taux de mise en forme effectif n’est pas configuré.

    Aucune vérification de validation n’est effectuée lorsque la VSA Tunnel-Tx-Speed-Method (26-94) est définie, de sorte qu’un message de journal système est généré dans cette situation pour rappeler à l’utilisateur de configurer le taux de mise en forme effectif.

    Bonne pratique :

    Nous vous recommandons d’utiliser un seul profil de service par session d’abonné pour affecter le taux de mise en forme en aval ou signaler un taux en amont. Si plusieurs profils de service dynamiques sont appliqués à la session d’abonné de sorte que chacun affecte le débit de mise en forme en aval ou signale le débit en amont, les valeurs du profil appliqué le plus récemment sont signalées par L2TP. La désactivation du dernier service appliqué n’entraîne pas la déclaration de la vitesse en amont par L2TP pour un profil de service existant (actif).

  • static: cette méthode permet au LAC de dériver la vitesse de la vitesse statique configurée de la couche 2. Pour les VLAN Ethernet, il s’agit du taux de mise en forme (consultatif) recommandé configuré sur l’interface logique PPPoE sous-jacente à l’interface abonné. Si le taux de mise en forme d’avis n’est pas configuré sur l’interface sous-jacente, la vitesse réelle du port physique sous-jacent est utilisée.

• À partir de la version 15.1R1 de Junos OS, vous pouvez configurer les valeurs de vitesse directement dans les VSA de Juniper Networks, Tx-Connect-Speed (26-162) et Rx-Connect-Speed (26-163). Ces VSA peuvent être renvoyés dans le message d’accès-acceptation de RADIUS. Si un seul des VSA est présent, le LAC utilise une méthode de vitesse de connexion pour déterminer la valeur de l’autre vitesse. Pour utiliser ces VSA, vous devez configurer RADIUS conformément à la documentation de votre serveur RADIUS.

• À partir de Junos OS version 15.1R1, vous pouvez configurer une méthode qui est transmise dans le VSA de Juniper Networks, Tunnel-Tx-Speed-Method (26-94). Si elle est configurée, cette VSA est renvoyée dans le message d’accès-acceptation RADIUS pour les abonnés individuels. La valeur VSA s’applique globalement plutôt qu’à un tunnel spécifique. La méthode configurée dans ce VSA spécifie la ressource que le LAC utilise pour définir la vitesse. Pour utiliser ce VSA, vous devez configurer RADIUS conformément à la documentation de votre serveur RADIUS.

• Lorsque les vitesses ne peuvent pas être déterminées d’une autre manière, la vitesse de port de l’interface d’abonné est utilisée.

Le Tableau 2 répertorie les méthodes disponibles par version.

Dans les versions 15.1, 16.1, 16.2 et 17.1 de Junos OS (qui prennent en charge la actual méthode), les valeurs de vitesse dans AVP 24 et AVP 38 ne sont généralement pas supérieures à la valeur appliquée par la CoS du côté LAC du réseau. Toute différence entre la vitesse signalée dans ces AVP et celle appliquée par le CoS est attribuable aux différences entre la configuration du CoS (de la source utilisée pour appliquer une vitesse en aval) et la méthode de vitesse de connexion Tx utilisée pour établir ces AVP.

Déterminer les vitesses de connexion initiales

Avant que le LAC puisse envoyer les vitesses de connexion initiales de transmission et de réception dans le message ICCN au LNS, il doit procéder comme suit :

1. Sélectionnez la méthode qu’il utilise pour dériver les vitesses.

2. Déterminez les vitesses.

Le LAC sélectionne la méthode comme suit :

1. Si la VSA Tunnel-Tx-Speed-Method (26-94) est présente, utilisez la méthode spécifiée par la valeur VSA.

2. Sinon, utilisez la méthode configurée dans la CLI avec l’instruction tx-connect-speed-method .

Le LAC détermine la vitesse initiale comme suit :

1. Si la méthode sélectionnée est none, le LAC n’inclut pas les vitesses d’émission et de réception dans l’ICCN.

2. Pour toute autre méthode sélectionnée, si les valeurs des VSA Tx-Connect-Speed (26-162) et Rx-Connect-Speed (26-163) sont différentes de zéro, le LAC envoie ces valeurs dans l’ICCN.

3. Si les valeurs VSA sont nulles, utilisez la méthode sélectionnée déterminée pour dériver les valeurs à envoyer.

Prenons les exemples suivants :

• VSA 26-94 est reçu avec ancp configuré comme méthode. La méthode CLI est configurée comme . none Le LAC sélectionne la valeur VSA 26-94, la ancp méthode.

  VSA 26-162 et VSA 26-163 sont reçus avec des valeurs non nulles. Le LAC envoie ces valeurs VSA dans l’ICCN.

• VSA 26-94 est reçu avec ancp configuré comme méthode. La méthode CLI est configurée comme . none Le LAC sélectionne la valeur VSA 26-94, la ancp méthode.

  VSA 26-162 et VSA 26-163 sont reçus avec des valeurs nulles. BAC utilise la ancp méthode pour dériver les valeurs à envoyer à l’ICCN.

• VSA 26-94 est reçu avec none configuré comme méthode. La méthode CLI est configurée comme . ancp Le LAC sélectionne la valeur VSA 26-94, noneet n’envoie pas de vitesses de connexion dans l’ICCN.

• VSA 26-94 n’est pas reçu. La méthode CLI est configurée comme . none Le LAC n’envoie pas de vitesses de connexion dans l’ICCN.

Mécanisme de repli pour les valeurs de vitesse de connexion

Lorsque le LAC a sélectionné une méthode pour calculer les vitesses de connexion, il revient à une méthode différente dans l’une des circonstances suivantes :

• Aucune ou les deux valeurs de vitesse de connexion n’ont été définies par la méthode sélectionnée (VSA 26-94 ou la CLI).

• La valeur de la vitesse de connexion est nulle.

Lorsqu’une valeur est disponible et différente de zéro, mais que l’autre ne l’est pas, seule la valeur non définie revient à une méthode différente. Il n’y a pas de repli lorsque la méthode sélectionnée est none, car cette méthode empêche le LAC de signaler les vitesses de connexion. La procédure de repli peut varier selon la version de Junos OS.

Prenons les exemples suivants :

• La méthode choisie est ANCP. La valeur ANCP de la vitesse de réception est égale à zéro. Le LAC envoie la valeur ANCP pour la vitesse de transmission, mais la valeur de réception revient à la méthode de balise PPPoE IA. Le LAC envoie la valeur de la balise IA pour la vitesse de réception.

• La méthode choisie est ANCP. La valeur ANCP de la vitesse de réception est égale à zéro. Le LAC envoie la valeur ANCP pour la vitesse de transmission, mais la valeur de réception revient à la méthode de balise PPPoE IA. La valeur de la balise IA pour la vitesse de réception est également égale à zéro, il revient donc à la méthode statique de couche 2. Ceci est disponible, donc le LAC envoie la valeur statique de couche 2 pour la vitesse de réception.

• La méthode sélectionnée est profil de service. Le profil de service n’est pas activé avant l’envoi de l’ICCN, de sorte que le LAC se rabat sur la méthode ANCP. Les valeurs ANCP de transmission et de réception sont disponibles et non nulles, de sorte que le LAC envoie ces valeurs dans l’ICCN.

  Le profil de service est activé par une modification d’autorisation (CoA) à une date ultérieure de la session. Si les mises à jour sont activées, le LAC envoie les valeurs du profil de service au LNS dans un message CSUN. Si les mises à jour ne sont pas activées, les valeurs du profil de service ne sont pas signalées au LNS.

  Notez que les mises à jour nécessitent que la méthode soit configurée dans la CLI. Par conséquent, VSA 26-94 ne doit pas être configuré ou reçu de manière à ce que la méthode du profil de service soit sélectionnée dans la configuration de la CLI.

À partir de la version 17.2R1 de Junos OS, la procédure de repli LAC est décrite dans le Tableau 3.

À partir de la version 15.1R1 de Junos OS, la procédure de repli LAC est décrite dans le Tableau 4.

À partir de la version 13.3R1 de Junos OS, la procédure de repli LAC est décrite dans le Tableau 5.