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

Transmission des informations de la ligne d’accès

Dans la topologie de réseau illustrée à la figure 1, lorsqu’un abonné initie une connexion via le CPE, le DSLAM relaie sa session PPPoE au routeur configuré en tant que LAC. Lorsque le routeur a établi la session PPPoE, le LAC lance un tunnel L2TP pour transmettre 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 les vitesses de liaison des sessions PPPoE sur la boucle locale. Le DSLAM envoie au routeur des chaînes ACI (Agent Circuit Id) et Agent Remote Id (ARI) 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 ligne d’accès. Les messages ANCP peuvent également inclure des attributs de ligne tels que les débits de données nets, minimum, maximum et réel en amont et en aval dans la TLV des attributs de ligne DSL. Le DSLAM peut également envoyer les attributs de 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 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 ligne d’accès ne sont pas requises pour lancer la session L2TP et l’établissement de cette session n’est pas retardé en attendant que les valeurs soient envoyées à partir du 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 le DSL et le PON. Si les informations PON sont déclarées à l’aide de 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 façonner le débit 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 avertir 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é pour ce faire, le LAC informe le LNS qu’il peut envoyer ces mises à jour en incluant l’option Connect Speed Update Enable AVP (98) dans le message ICRQ au démarrage de la session L2TP. L’absence de l’option Connect Speed Update Enable AVP (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 avertit l’agent ANCP. L’agent ANCP informe ensuite le LAC, qui transmet à son tour cette information au LNS en envoyant un message CSUN (Connect-Speed-Update-Notification) qui inclut les vitesses mises à jour dans un AVP de mise à jour de vitesse de connexion (97) pour chaque session. Le LAC recueille les mises à jour de vitesse de connexion et les envoie par lots afin de minimiser à la fois la surcharge de performance sur le LAC et la quantité de trafic généré à la suite de ces notifications.

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

La présence de l’AVP (98) pour activer la mise à jour de la vitesse de connexion dans le message ICRQ informe également le LNS que le LAC répond s’il reçoit un message CSURQ (Connect-Speed-Update-Request) 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 Activer la mise à jour 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 vitesse de connexion (97) pour chaque session. Si aucune modification n’a été apportée aux vitesses de connexion à ce moment-là, le LAC inclut simplement les valeurs initiales de vitesse de connexion qui ont été déclarées dans AVP 24 et AVP 38.

Lorsque vous activez les mises à jour de vitesse de connexion globalement 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 pour qu’elle ancp soit ou service-profile.

Mises à jour de la vitesse de connexion sur le LNS

À partir de Junos OS version 17.4R1, 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 de la part de LAC.

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

Interaction entre les configurations globales et par destination

Vous pouvez configurer le LAC pour transférer les informations de 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 le configurer 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 ALC 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 à 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 access-line-information envoie au LNS, ou pour configurer le LNS afin qu’il reçoive et traite ces informations :

• [edit services l2tp]: configure le transfert à l’échelle mondiale pour toutes les destinations.

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

Pour configurer le LAC afin d’envoyer des mises à jour de vitesse de connexion ou le LNS pour recevoir et traiter les mises à jour, incluez l’option avec l’instruction connection-speed-update 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 omettant connection-speed-update.

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

Les valeurs rapporté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 :

  Note:

  À partir de Junos OS version 13.3R1, la disponibilité et la prise en charge des méthodes varient d’une version de Junos OS à l’autre, 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 logicielle que vous utilisez.

  • actual: la vitesse correspond au 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 méthode lorsque vous avez besoin que la valeur rapportée soit la vitesse en aval appliquée par la actual stratégie CoS locale. D’autres méthodes peuvent différer de cette valeur appliqué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 de l’interface de ligne de commande échoue si actual elle est configurée mais que la fréquence de mise en forme effective n’est pas configurée.

    Aucune vérification de validation n’est effectuée lorsque le VSA Tunnel-Tx-Speed-Method (26-94) est défini, 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 correspond à 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 et 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 du LNS dans le message CSUN.

  • none—cette option empêche l’ALC 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 Encapsulation Overhead (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 soit service-profile. Le profil n’est pas activé avant l’envoi de l’ICCN et revient à la balise PPPoE IA, 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é sur le nœud L3 en fonction de la stratégie locale. La vitesse en amont (Rx) est extraite de la valeur configurée dans le profil de service ; Cette valeur n’est pas ajustée.

      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 Junos OS version 18.1R1, vous pouvez utiliser un profil de service dynamique pour indiquer 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 abonné, authd détermine si le nom du profil de service transmis dans le VSA Activate-Service (26-65) de Juniper Networks dans le message RADIUS Access-Accept correspond au nom du 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 du profil de service, soit des paramètres transmis par le VSA. Voir Spécification d’un profil de service limitant le débit pour les vitesses de connexion L2TP pour plus d’informations sur cette méthode.

    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 de l’interface de ligne de commande échoue lorsqu’elle service-profile est configurée, mais que la fréquence de mise en forme effective n’est pas configurée.

    Aucune vérification de validation n’est effectuée lorsque le VSA Tunnel-Tx-Speed-Method (26-94) est défini, 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.

    Meilleure pratique :

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

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

• À partir de Junos OS version 15.1R1, vous pouvez configurer les valeurs de vitesse directement dans les VSA Juniper Networks, Tx-Connect-Speed (26-162) et Rx-Connect-Speed (26-163). Ces VSA peuvent être renvoyés dans le message RADIUS Access-Accept. 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 Juniper Networks, Tunnel-Tx-Speed-Method (26-94). S’il est configuré, ce VSA est renvoyé dans le message RADIUS Access-Accept 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 abonné est utilisée.

Le tableau 2 présente les méthodes disponibles par rejet.

Dans les versions 15.1, 16.1, 16.2 et 17.1 de Junos OS (qui prennent en charge la méthode), les valeurs de vitesse dans AVP 24 et AVP 38 ne sont généralement pas supérieures à la actual valeur appliquée par CoS du côté LAC du réseau. Toute différence entre la vitesse indiquée dans ces AVP et celle appliquée par CoS est attribuable aux différences entre la configuration 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étermination des vitesses de connexion initiales

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

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

2. Déterminez les vitesses.

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

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

2. Sinon, utilisez la méthode configurée dans l’interface de ligne de commande 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 sous la forme 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 différentes de zéro. 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 sous la forme 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. Le LAC utilise la ancp méthode pour dériver les valeurs à envoyer dans l’ICCN.

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

• VSA 26-94 n’est pas reçu. La méthode CLI est configurée sous la forme 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 :

• Une ou les deux valeurs de vitesse de connexion n’ont pas été définies par la méthode sélectionnée (VSA 26-94 ou l’interface de ligne de commande).

• La valeur de la vitesse de connexion est zéro.

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 solution de secours 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 secours peut varier selon la version de Junos OS.

Prenons les exemples suivants :

• La méthode sélectionnée 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 retombe à 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 sélectionnée 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 retombe à la méthode de balise PPPoE IA. La valeur de la balise IA pour la vitesse de réception est également égale à zéro, de sorte qu’elle revient à la méthode statique de couche 2. Ceci étant disponible, 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’étant pas activé avant l’envoi de l’ICCN, le LAC revient à la méthode ANCP. Les valeurs ANCP d’émission 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 un changement d’autorisation (CoA) à une date ultérieure pour la session. Si les mises à jour sont activées, le LAC envoie les valeurs de 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 l’interface de ligne de commande. Par conséquent, VSA 26-94 ne doit pas être configuré ou reçu afin que la méthode de profil de service soit sélectionnée dans la configuration de l’interface de ligne de commande.

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

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

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