Líneas de acceso de suscriptores y velocidades de conexión de L2TP

Reenvío de información de línea de acceso

En la topología de red que se muestra en la Figura 1, cuando un suscriptor inicia una conexión a través del CPE, el DSLAM retransmite la sesión PPPoE del suscriptor al enrutador configurado como LAC. Cuando el enrutador ha establecido la sesión PPPoE, el LAC inicia un túnel L2TP para reenviar los paquetes PPP encapsulados del suscriptor a la red del proveedor.

Paralelamente a la sesión PPPoE, una conexión ANCP entre el DSLAM y el agente ANCP en el enrutador transmite información sobre el bucle local del suscriptor, así como las velocidades de enlace de las sesiones PPPoE en el bucle local. El DSLAM envía al enrutador cadenas de ID de circuito de agente (ACI) e ID remoto de agente (ARI) que identifican de forma exclusiva la interfaz de recepción del DSLAM; esta información está codificada en los mensajes de puerto activo y descendente de ANCP como TLV de identificación de línea de acceso. Los mensajes ANCP también pueden incluir atributos de línea como velocidades de datos ascendentes y descendentes netas mínimas, máximas y reales en el TLV de atributos de línea DSL. El DSLAM también puede enviar los atributos de línea de acceso en etiquetas específicas del proveedor que inserta en los mensajes PADI y PADR.

Figura 1: Ejemplo de topología de red L2TP

Información de la línea de acceso AVP

L2TP es compatible con los AVP enumerados en la Tabla 1 para llevar esta información. La información de la línea de acceso no es necesaria para que se inicie la sesión L2TP y el establecimiento de esa sesión no se retrasa a la espera de que se envíen los valores desde el nodo de acceso. El contenido del mensaje ICRQ generalmente varía entre las líneas de acceso DSL y las líneas de acceso PON. Los AVP 1, 2, 3 y 6 se utilizan para la identificación de la línea de acceso tanto para DSL como para PON. Si la información de PON se notifica mediante AVP DSL, el contenido es el mismo que para el acceso DSL.

La información de la línea de acceso proporcionada por los AVP en los mensajes ICRQ se transmite a RADIUS en los VSA del foro DSL. No se utiliza para dar forma a la velocidad de tráfico en las líneas de acceso de los suscriptores.

Actualizaciones de velocidad de conexión en el LAC

Puede configurar el LAC para que notifique al LNS cuando la velocidad de la conexión del suscriptor cambie de los valores comunicados inicialmente al LNS por AVP 24 (velocidad de transmisión) y AVP 38 (velocidad de recepción) en los mensajes conectados a llamadas entrantes (ICCN). Cuando se configura para ello, el LAC informa al LNS de que puede enviar estas actualizaciones incluyendo el AVP de activación de actualización de velocidad de conexión (98) en el mensaje ICRQ cuando se inicia la sesión L2TP. La ausencia de Connect Speed Update Enable AVP (98) en el mensaje ICRQ indica que el LAC no envía actualizaciones durante la duración de la sesión.

Cuando cambia la velocidad de conexión, DSLAM notifica al agente ANCP. Luego, el agente ANCP notifica al LAC y, a su vez, el LAC transmite esta información al LNS mediante el envío de un mensaje Connect-Speed-Update-Notification (CSUN) que incluye las velocidades actualizadas en un AVP de actualización de velocidad de conexión (97) para cada sesión. El LAC recopila actualizaciones de velocidad de conexión y las envía por lotes para minimizar la sobrecarga de rendimiento en el LAC y la cantidad de tráfico generado como resultado de estas notificaciones.

Las velocidades iniciales en los mensajes ICCN y las velocidades actualizadas en los mensajes CSUN son utilizadas por CoS para dar forma a la velocidad de tráfico para las líneas de acceso de los suscriptores.

La presencia de Connect Speed Update Enable AVP (98) en el mensaje ICRQ también informa al LNS que el LAC responde si recibe un mensaje Connect-Speed-Update-Request (CSURQ) de un LNS.

Un LNS de terceros puede enviar un mensaje CSURQ en cualquier momento durante la vida de un túnel para solicitar la velocidad de conexión de transmisión y recepción actual para una o más sesiones L2TP. El LNS incluye los ID de sesión remoto (relativos al LNS) en el mensaje CSURQ. Si el LAC ha enviado previamente la actualización de velocidad de conexión Habilitar AVP (98) para las sesiones solicitadas, responde al CSURQ con un mensaje CSUN que incluye la actualización de velocidad de conexión AVP (97) para cada sesión. Si no se han producido cambios en las velocidades de conexión en este momento, el LAC simplemente incluye los valores iniciales de velocidad de conexión que se informaron en AVP 24 y AVP 38.

Cuando se habilitan las actualizaciones de velocidad de conexión, ya sea globalmente o para un LNS específico, el LAC no envía mensajes CSUN a menos que también haya configurado la tx-connect-speed instrucción para que sea ancp o service-profile.

Actualizaciones de velocidad de conexión en LNS

A partir de la versión 17.4R1 de Junos OS, un enrutador de la serie MX configurado como LNS puede procesar la información de la línea de acceso del suscriptor y las actualizaciones de velocidad de conexión que recibe del LAC. El enrutador de la serie MX no puede enviar mensajes CSURQ para solicitar actualizaciones del LAC.

Las velocidades iniciales en los mensajes ICCN y las velocidades actualizadas en los mensajes CSUN son utilizadas por CoS para dar forma a la velocidad de tráfico para las líneas de acceso de los suscriptores.

Interacción entre las configuraciones globales y por destino

Puede configurar la LAC para reenviar la información de la línea de acceso en el mensaje ICRQ que envía al LNS y puede configurar el LNS para recibir y procesar esa información. Puede configurarlo globalmente para todos los destinos (puntos de conexión) o para un destino específico. La configuración por destino le permite limitar la transmisión a un LNS individual o a un conjunto de LNS, o la recepción desde un LAC individual o un conjunto de LAC. Esto resulta útil si sabe que algunas puertas de enlace remotas no admiten esta función o tienen una implementación incorrecta.

Incluya la access-line-information instrucción en uno o ambos de los siguientes niveles de jerarquía en el LAC o LNS, respectivamente, para configurar el LAC para reenviar la información de la línea de acceso en el mensaje ICRQ que envía al LNS, o para configurar el LNS para recibir y procesar esa información:

• [edit services l2tp]: configura el reenvío globalmente para todos los destinos.

• [edit services l2tp destination ip-address]: configura el reenvío para un destino específico.

Para configurar el LAC para enviar actualizaciones de velocidad de conexión o el LNS para recibir y procesar las actualizaciones, incluya la connection-speed-update opción con la access-line-information instrucción en el nivel de jerarquía adecuado en el LAC o LNS, respectivamente.

La configuración global y por destino interactúan de la siguiente manera:

• Información de línea de acceso: cuando el reenvío por LAC o el procesamiento por LNS está habilitado globalmente, no puede deshabilitar la configuración global para un destino específico.

• Actualizaciones de velocidad de conexión: cuando el reenvío por parte de LAC o el procesamiento por LNS está habilitado globalmente, puede deshabilitar la configuración global para un destino específico (LNS o LAC) especificando access-line-information para el destino y omitiendo connection-speed-update.

Métodos para determinar los valores de velocidad notificados al LNS

Los valores notificados al LNS se pueden derivar de las siguientes maneras:

• Puede configurar un método globalmente para el LAC con la tx-connect-speed-method instrucción en el [edit services l2tp] nivel de jerarquía. Puede especificar cualquiera de los siguientes métodos para determinar el origen de las velocidades de conexión:

  Nota:

  A partir de la versión 13.3R1 de Junos OS, la disponibilidad y el soporte de los métodos varían según la versión de Junos OS, como se describe en la tabla 2. La siguiente lista incluye todos los métodos históricos; Es posible que algunos de los métodos no sean compatibles con la versión de software que está utilizando.

  • actual: la velocidad es la velocidad real del tráfico descendente aplicada en el nodo del programador de sesiones según la política de control de tráfico local. Solo la velocidad de conexión de transmisión está disponible con este método, por lo que la velocidad de transmisión de recepción está determinada por el esquema de reserva. Utilice el actual método cuando necesite que el valor notificado sea la velocidad descendente impuesta por la política de CoS local. Otros métodos pueden variar de este valor forzado.

    El actual método solo se admite cuando la effective shaping-rate instrucción se incluye en el nivel de [edit chassis] jerarquía. La comprobación de confirmación de la CLI falla si actual está configurada, pero la velocidad de modelación efectiva no está configurada.

    No se realiza ninguna comprobación de confirmación cuando se establece el VSA Tunnel-Tx-Speed-Method (26-94), por lo que se genera un mensaje de registro del sistema en esta situación para recordar al usuario que configure la velocidad de modelación efectiva.

  • ancp: la velocidad es el valor ascendente y descendente de origen ANCP ajustado que resulta de una corrección porcentual configurada de los valores reales de ANCP. El ajuste se aplica por DSL para tener en cuenta las diferencias de encapsulación ATM entre el BNG y el bucle de acceso y para la sobrecarga de transporte de capa 1. La velocidad inicial enviada al LNS es el valor ANCP notificado en el momento en que se envía el ICCN. Cualquier cambio posterior se envía como actualizaciones al LNS en el mensaje CSUN.

  • none: esta opción impide que el LAC envíe AVP 24 o AVP 38 en el mensaje ICCN; en consecuencia, tampoco se envían mensajes CSUN. El LNS tiene que establecer su propia política ascendente y descendente en ausencia de estos valores. Esta opción anula los VSA de Juniper Networks RADIUS, Tx-Connect-Speed (26-162) y Rx-Connect-Speed (26-163), así como cualquier otro método configurado para la velocidad de conexión.

  • pppoe-ia-tags: la velocidad se deriva del valor enviado desde el DSLAM al LAC en las etiquetas de agente intermedio (IA) del protocolo punto a punto sobre Ethernet (PPPoE). Para las interfaces Ethernet, la velocidad es un valor no ajustado; para las interfaces ATM, el valor puede ser un valor ajustado si la etiqueta incluye el atributo de sobrecarga de encapsulación (0x90).

    Este valor de velocidad se transmite cuando se establece la sesión L2TP. Aunque el valor de la etiqueta PPPoe IA no cambia durante una sesión, la velocidad informada al LAC puede cambiar. Por ejemplo, supongamos que el método configurado es service-profile. El perfil no se activa antes de enviar el ICCN y vuelve a la etiqueta PPPoE IA, que se envía en el mensaje ICCN. Cuando el perfil de servicio se activa más tarde, las tasas del perfil de servicio se envían en un mensaje de actualización (si las actualizaciones están configuradas).

  • service-profile: dependiendo de la versión de Junos OS, hay dos maneras de utilizar los perfiles de servicio para proporcionar velocidades de conexión. Un método usa las velocidades del perfil de servicio solo en mensajes CSUN, el otro método en mensajes ICCN.

    • En mensajes CSUN: la velocidad descendente (Tx) se deriva de la CoS real que se aplica en el nodo L3 según la política local. La velocidad ascendente (Rx) se toma del valor configurado en el perfil de servicio; No se realiza ningún ajuste a este valor.

      De forma predeterminada, los perfiles de servicio no se activan antes de que se establezca la sesión del suscriptor, por lo que este método recurre a otro método para los valores enviados en el ICCN. Cuando el perfil se activa más adelante, esas velocidades se envían al LNS en un mensaje CSUN, si las actualizaciones están habilitadas.

    • En mensajes ICCN: a partir de Junos OS versión 18.1R1, puede utilizar un perfil de servicio dinámico para proporcionar las velocidades de conexión incluidas en AVP 38 y AVP 24 en el mensaje ICCN cuando se negocia la sesión L2TP. Al iniciar sesión del suscriptor, authd determina si el nombre del perfil de servicio transmitido en el VSA de servicio activado de Juniper Networks (26-65) en el mensaje de aceptación de acceso de RADIUS coincide con el nombre del perfil de servicio configurado con la service-rate-limiter instrucción en el [edit access] nivel de jerarquía. Si los nombres coinciden, las velocidades se derivan de los valores predeterminados del perfil de servicio o de los parámetros pasados por el VSA. Consulte Especificación de un perfil de servicio de limitación de velocidad para velocidades de conexión L2TP para obtener más información sobre este método.

    El service-profile método solo se admite cuando la effective shaping-rate instrucción se incluye en el nivel de [edit chassis] jerarquía. La comprobación de confirmación de la CLI falla cuando service-profile está configurada, pero la velocidad de modelación efectiva no está configurada.

    No se realiza ninguna comprobación de confirmación cuando se establece el VSA Tunnel-Tx-Speed-Method (26-94), por lo que se genera un mensaje de registro del sistema en esta situación para recordar al usuario que configure la velocidad de modelación efectiva.

    Práctica recomendada:

    Le recomendamos que use solo un perfil de servicio por sesión de suscriptor para afectar la velocidad de modelado descendente o informar una velocidad ascendente. Si se aplica más de un perfil de servicio dinámico a la sesión del suscriptor, de modo que cada uno afecte a la velocidad de modelado descendente o informe la velocidad ascendente, L2TP informa de los valores del perfil aplicado más recientemente. La desactivación del servicio aplicado más recientemente no da como resultado que L2TP informe la velocidad ascendente de un perfil de servicio existente (activo).

  • static: este método hace que el LAC derive la velocidad de la velocidad estática configurada de capa 2. En el caso de las VLAN Ethernet, esta es la velocidad de modelación recomendada (recomendada) configurada en la interfaz lógica PPPoE subyacente a la interfaz del suscriptor. Si la velocidad de modelación de aviso no está configurada en la interfaz subyacente, se utilizará la velocidad real del puerto físico subyacente.

• A partir de la versión 15.1R1 de Junos OS, puede configurar los valores de velocidad directamente en los VSA de Juniper Networks, Tx-Connect-Speed (26-162) y Rx-Connect-Speed (26-163). Estos VSA se pueden devolver en el mensaje de aceptación de acceso de RADIUS. Si solo está presente uno de los VSA, el LAC utiliza un método de velocidad de conexión para determinar el valor de la otra velocidad. Para utilizar estos VSA, debe configurar RADIUS de acuerdo con la documentación del servidor RADIUS.

• A partir de la versión 15.1R1 de Junos OS, puede configurar un método que se transmite en el VSA de Juniper Networks, Tunnel-Tx-Speed-Method (26-94). Si está configurado, este VSA se devuelve en el mensaje de aceptación de acceso de RADIUS para suscriptores individuales. El valor VSA se aplica globalmente en lugar de a un túnel específico. El método configurado en este VSA especifica el recurso que utiliza el LAC para establecer la velocidad. Para utilizar este VSA, debe configurar RADIUS de acuerdo con la documentación del servidor RADIUS.

• Cuando las velocidades no se pueden determinar de otra manera, se utiliza la velocidad de puerto de la interfaz del suscriptor.

En el cuadro 2 se enumeran los métodos disponibles por versión.

En las versiones 15.1, 16.1, 16.2 y 17.1 de Junos OS (que admiten el actual método), los valores de velocidad en AVP 24 y AVP 38 no suelen ser mayores que el valor aplicado por CoS en el lado LAC de la red. Cualquier diferencia entre la velocidad informada en estos AVP y la aplicada por CoS es atribuible a diferencias entre la configuración de CoS (de la fuente que se usa para aplicar una velocidad descendente) y el método de velocidad de conexión TX utilizado para establecer estos AVP.

Determinación de las velocidades de conexión iniciales

Antes de que el LAC pueda enviar las velocidades de conexión iniciales de transmisión y recepción en el mensaje ICCN al LNS, tiene que hacer lo siguiente:

1. Seleccione el método que utiliza para derivar las velocidades.

2. Determine las velocidades.

El LAC selecciona el método de la siguiente manera:

1. Si el VSA Tunnel-Tx-Speed-Method (26-94) está presente, utilice el método especificado por el valor VSA.

2. De lo contrario, utilice el método configurado en la CLI con la tx-connect-speed-method instrucción.

El LAC determina la velocidad inicial de la siguiente manera:

1. Si el método seleccionado es none, el LAC no incluye las velocidades de transmisión y recepción en el ICCN.

2. Para cualquier otro método seleccionado, si los valores de los VSA Tx-Connect-Speed (26-162) y Rx-Connect-Speed (26-163) no son cero, el LAC envía esos valores al ICCN.

3. Si los valores de VSA son cero, utilice el método seleccionado determinado para derivar los valores que se van a enviar.

Considere los siguientes ejemplos:

• VSA 26-94 se recibe con ancp configurado como el método. El método de la CLI está configurado como none. El LAC selecciona el valor VSA 26-94, el ancp método.

  VSA 26-162 y VSA 26-163 se reciben con valores distintos de cero. El LAC envía estos valores de VSA en el ICCN.

• VSA 26-94 se recibe con ancp configurado como el método. El método de la CLI está configurado como none. El LAC selecciona el valor VSA 26-94, el ancp método.

  VSA 26-162 y VSA 26-163 se reciben con valores cero. El LAC utiliza el ancp método para derivar los valores que se enviarán en el ICCN.

• VSA 26-94 se recibe con none configurado como el método. El método de la CLI está configurado como ancp. El LAC selecciona el valor noneVSA 26-94 y no envía velocidades de conexión en el ICCN.

• VSA 26-94 no se recibe. El método de la CLI está configurado como none. El LAC no envía velocidades de conexión en el ICCN.

Mecanismo de reserva para valores de velocidad de conexión

Cuando el LAC ha seleccionado un método para derivar las velocidades de conexión, recurre a un método diferente en cualquiera de las siguientes circunstancias:

• El método seleccionado (VSA 26-94 o la CLI) no ha establecido uno o ambos valores de velocidad de conexión.

• El valor de la velocidad de conexión es cero.

Cuando un valor está disponible y no es cero, pero el otro no, solo el valor no establecido vuelve a un método diferente. No hay reserva cuando el método seleccionado es none, ya que este método impide que el LAC informe de las velocidades de conexión. El procedimiento de reserva puede variar según la versión de Junos OS.

Considere los siguientes ejemplos:

• El método seleccionado es ANCP. El valor ANCP para la velocidad de recepción es cero. El LAC envía el valor ANCP para la velocidad de transmisión, pero el valor de recepción vuelve al método de etiqueta PPPoE IA. El LAC envía el valor de la etiqueta IA para la velocidad de recepción.

• El método seleccionado es ANCP. El valor ANCP para la velocidad de recepción es cero. El LAC envía el valor ANCP para la velocidad de transmisión, pero el valor de recepción vuelve al método de etiqueta PPPoE IA. También se encuentra que el valor de la etiqueta IA para la velocidad de recepción es cero, por lo que vuelve al método estático de capa 2. Esto está disponible, por lo que el LAC envía el valor estático de capa 2 para la velocidad de recepción.

• El método seleccionado es el perfil de servicio. El perfil de servicio no se activa antes de enviar el ICCN, por lo que el LAC recurre al método ANCP. Tanto los valores de ANCP de transmisión como los de recepción están disponibles y son distintos de cero, por lo que el LAC envía estos valores en el ICCN.

  El perfil de servicio se activa mediante un cambio de autorización (CoA) en algún momento posterior para la sesión. Si las actualizaciones están habilitadas, el LAC envía los valores del perfil de servicio al LNS en un mensaje CSUN. Si las actualizaciones no están habilitadas, los valores del perfil de servicio no se informan al LNS.

  Tenga en cuenta que las actualizaciones requieren que el método se configure en la CLI. Por consiguiente, VSA 26-94 no debe configurarse ni recibirse para que se seleccione el método de perfil de servicio en la configuración de la CLI.

A partir de Junos OS versión 17.2R1, el procedimiento de reserva de LAC es el que se describe en la Tabla 3.

A partir de Junos OS versión 15.1R1, el procedimiento de reserva de LAC es el descrito en la Tabla 4.

A partir de la versión 13.3R1 de Junos OS, el procedimiento de reserva de LAC es el descrito en la Tabla 5.