Tabla de contenido
Publicidad
El CAP DEBE soportar tráfico de multidifusión de WAN-a-LAN puenteando de manera
transparente los mensajes IGMP de WAN-a-LAN y los paquetes multidifusión IP de WAN a LAN
como se describe en RFC 2236.
Si el modo de tratamiento de paquetes primario, cabhCapPrimaryMode, se fija a transferencia,
todos los mensajes IGMP de LAN-a-WAN DEBEN puentearse de manera transparente.
Si el modo de tratamiento de paquetes primario, cabhCapPrimaryMode, se fija a C-NAPT, la
dirección IP de origen de todos los mensajes IGMP de LAN-a-WAN, originados por dispositivos IP
de LAN que residen en el dominio LAN-Trans, DEBEN traducirse a la dirección IP de WAN-Data
que se utiliza para las correspondencias C-NAPT, y a continuación enviarse a la red WAN.
Si el modo de tratamiento de paquetes primario, cabhCapPrimaryMode, se fija a C-NAT, la
dirección IP de origen de todos los mensajes IGMP de LAN a WAN (originados por dispositivos IP
de LAN que residen en el dominio LAN-Trans y que tienen una dirección IP que forma parte de una
correspondencia C-NAT existente) DEBE traducirse a la dirección IP de WAN-Data que está
siendo utilizada en esa correspondencia C-NAT, y a continuación enviarse a la red WAN.
8.3.2
Requisitos del tratamiento de paquetes
El CAP DEBE soportar el modo transferencia, el modo de encaminamiento transparente C-NAT y
el modo de encaminamiento transparente C-NAPT, además el CAP DEBE soportar la selección de
este modo primario de tratamiento de paquetes mediante el objeto de la MIB
cabhCapPrimaryMode.
Si el modo primario de tratamiento de paquetes, cabhCapPrimaryMode, tiene el valor C-NAT, el
CAP DEBE asegurarse de que exista una dirección IP disponible en el grupo de direcciones
IP WAN-Data suministrada por la cabecera (con una licencia activa DHCP) antes de intentar
utilizar esta dirección IP como parte de la correspondencia C-NAT. Si el CAP no pudiera crear una
correspondencia C-NAT, por haberse agotado el grupo de direcciones IP WAN-Data, debería
generar un evento normal (definido en el anexo B).
El CAP DEBE fijar a cero los números de puerto de la WAN y la LAN (cabhCapMappingWanPort
y cabhCapMappingLanPort, respectivamente) del cuadro de correspondencia de CAP para cada
correspondencia C-NAT dinámica que cree.
Si el operador de cable crea o modifica una fila del cuadro de correspondencia CAP, es decir, si se
crea una fila mediante el método de correspondencia estática (cabhCapMappingMethod = static(1)),
Y
los
objetos
de
número
de
puerto
de
la
fila
(cabhCapMappingLanPort
y
cabhCapMappingWanPort) no se han especificado, el CAP DEBE efectuar la anotación cero para
cabhCapMappingLanPort y cabhCapMappingWanPort en esa fila.
El CAP NO DEBE traducir el número de puerto de ningún paquete cuya dirección IP aparezca en el
cuadro de correspondencia CAP con número de puerto igual a cero.
Si el modo primario de tratamiento de paquetes cabhCapPrimaryMode, tiene el valor C-NAPT, el
CAP DEBE asegurarse de que exista una dirección IP de la WAN vigente (con una licencia DHCP
activa suministrada por la cabecera) antes de intentar utilizar dicha dirección IP como parte de la
correspondencia C-NAPT. Si el CAP no pudiese crear una correspondencia C-NAPT, por no tener
una dirección IP de la WAN activa o por no quedar números de puerto, debería generar un evento
normal (definido en el anexo B).
El tráfico unidifusión LAN-a-LAN nunca DEBE encaminarse ni puentearse hacia el exterior de una
interfaz WAN.
Cuando expire la licencia DHCP de una dirección IP de WAN-Data (que forma parte de la
correspondencia C-NAT o C-NAPT), DEBERÁN suprimirse todas las correspondencias asociadas
con esa dirección IP del cuadro cabhCapMappingTable.
106
Rec. UIT-T J.191 (03/2004)
Publicidad
Tabla de contenido
