v El adaptador de terminal no da automáticamente soporte al protocolo de autenticación de
reconocimiento de identificación (CHAP). Sin embargo, si se establece el valor S84=0 sí que se puede
realizar la autenticación CHAP en el servidor iSeries.
v El servidor iSeries no puede determinar en qué momento termina la conexión cuando se supervisa la
señal de equipo de datos preparado (DSR) del adaptador de terminal. Esto supone exponer el sistema
a un riesgo de seguridad.
Motorola BitSurfr Pro RDSI:
Este adaptador de terminal no está recomendado para el servidor iSeries por las siguientes razones:
v El adaptador de terminal no da soporte a las conexiones de módem analógico V.34. Sin embargo,
puede dar soporte a las conexiones de módem analógico V.34 si se emplea la conexión externa RJ-11.
v Actualmente el adaptador de terminal no da soporte a las conexiones V.90.
v El adaptador de terminal no puede conectarse al servidor iSeries a velocidades superiores a los
115.200 bps.
v El adaptador de terminal no da automáticamente soporte a la autenticación CHAP. Sin embargo, si se
establece el valor @M2=C sí que se puede realizar la autenticación CHAP en el servidor iSeries.
v El adaptador de terminal no permite responder automáticamente a las llamadas PPP de un solo enlace
ni a las llamadas PPP multienlace. El adaptador de terminal remoto de origen debe estar configurado
con el mismo protocolo (un solo enlace o multienlace) que el adaptador de terminal que responde.
v El mecanismo de control de flujo por hardware del servidor iSeries no funciona bien con este adaptador
de terminal. Se produciría una reducción del rendimiento cuando el servidor iSeries enviase datos a
través de una conexión PPP multienlace.
Consideraciones sobre el ancho de banda - Multienlace
Puede ocurrir que en algunas ocasiones, pero no en todas, se necesite más ancho de banda para
completar algunas tareas. En tales casos, puede no estar justificada la adquisición de hardware
especializado y de líneas de comunicaciones de precio elevado. El protocolo multienlace (MP) PPP
permite agrupar múltiples enlaces PPP para formar un solo enlace virtual o "paquete compuesto". El
resultado de agrupar múltiples enlaces aumenta el ancho de banda efectivo total entre dos sistemas si se
utilizan módems y líneas telefónicas estándar. Un factor que limita el número máximo de enlaces
permitidos en un paquete compuesto MP es el número de módems y líneas telefónicas que están
disponibles en los dos extremos del enlace PPP. Para establecer una conexión multienlace, los dos
extremos del enlace PPP han de dar soporte al protocolo multienlace. El protocolo multienlace viene
documentado como petición de comentarios estándar RFC 1990. Podrá hallar más información sobre las
RFC en http://www.rfc-editor.org.
Ancho de banda a petición:
La capacidad de añadir y quitar enlaces físicos de manera dinámica permite configurar un sistema para
que suministre ancho de banda en la medida de lo necesario. Este enfoque, al que se suele llamar
"ancho de banda a petición", permite que solo se pague el ancho de banda adicional que realmente se
utilice. Para beneficiarse de las ventajas del "ancho de banda a petición", debe haber al menos un similar
con capacidad para supervisar la utilización del ancho de banda total disponible actualmente en un
paquete compuesto MP. Luego, cuando la utilización del ancho de banda supere los valores definidos en
la configuración, se podrán añadir o quitar enlaces en el paquete compuesto. El protocolo de asignación
de ancho de banda (BAP) permite a los similares negociar las acciones de añadir o quitar enlaces en un
paquete compuesto MP. En la RFC 2125 hallará documentación relacionada con el protocolo de
asignación de ancho de banda (BAP) y con el protocolo de control de asignación de ancho de banda
(BACP) de PPP.
28
iSeries: Servicios de acceso remoto: conexiones PPP