AAL5 Especialmente apto para servicio UBR y ABR, pero
también puede utilizarse sobre CBR y VBR cuando hace falta
calidad de servicio. Funcionamiento: Subcapa CS: Añade una
cola al mensaje recibido de la aplicación y rellena a
múltiplo de 48. Subcapa SAR: Corta el mensaje en trocitos
de 48 bytes y lo acomoda en celdas. Coloca a 1 el último
bit (clase) del campo PTI en la cabecera de la última
celda
Formato de mensaje en la subcapa CS de AAL5 0-65535 0-47 1 1 2 4
El mensaje recibido de la aplicación. Asegura que la
longitud total es múltiplo de 48. User to User. A
disposición de la aplicación. Actualmente no se
utiliza. Common Part Indicator. Indica el significado del resto
de los campos. De momento sólo se ha definido uno. Indica
la longitud de la carga útil (para que el receptor sepa
donde empieza el relleno). El mismo que se utiliza habitualmente
en LANs. Carga útil: Relleno: UU: CPI: Long.: CRC:
AAL 5 Cab Cab Cab Cab Mensaje recibido de la aplicación
Paquete (subcapa CS) Celdas ATM Última celda clase 1
(campo PTI a xx1) Datos Datos Cola AAL 5(longitud,CRC) Relleno 8
bytes El receptor detecta el final por la celda clase 1,
reensambla los datos, comprueba el CRC y usa la longitud para
quitar el relleno Celdas de 48 bytes (subcapa SAR) Se respeta el
orden de las celdas Cab
Sumario Protocolo AAL5 de ATM Transmisión de datos en ATM
Transmisión de datos en Frame Relay
Transporte de datos sobre ATM El transporte de datos
pertenecientes a otros protocolos (IP, IPX, etc.) se ha
convertido en la principal aplicación de ATM Existen
básicamente dos tipos de soluciones, las estandarizadas
por el IETF y las del ATM Forum: IETF: Multiprotocol
encapsulation over AAL5: RFC 1483 (7/93) Classical IP and ARP
over ATM: RFC 1577 (1/94) y otros MPLS (Multiprotocol Label
Switching): RFC 2547 (3/99), 2702 (9/99) y otros en
discusión ATM Forum: LAN Emulation Versión 1.0
(1995-96), V. 2.0 (1997-99) MPOA (MultiProtocol Over ATM) v. 1.0
(1997-98), v. 1.1 (1999- )
Multiprotocol Encapsulation over AAL5 (RFC 1483) Los paquetes de
red (IP, IPX, Appletalk, etc.) se meten en mensajes AAL5 El
soporte multiprotocolo se consigue: Estableciendo un VC diferente
para cada protocolo, o Añadiendo una cabecera LLC/SNAP
(IEEE 802.2) a cada paquete (como en las LAN) La
resolución de direcciones ATM-nivel_de_red se hace de
forma manual y estática. Cada host mantiene su propia
tabla de equivalencias. Se pueden utilizar PVCs o SVCs
VCs AAL5 VC AAL5 LLC/SNAP (IP + Atalk) RFC 1483: Multiplexado por
VCs RFC 1483: Multiplexado por LLC/SNAP (802.2) IP IP ATalk ATalk
IP IP ATalk Atalk IP ATalk
VC multiprotocolo IP y AppleTalk (LLC/SNAP) IP IP ATalk Atalk IP
VC IP solo 130.206.211.1/29 130.206.211.2/29 130.206.211.3/29
VPI/VCI 1/225 VPI/VCI 3/58 Ejemplo configuración
conexiones ATM RFC1483 gordius Las tres direcciones IP se
encuentran en la misma red /29 (ocho direcciones)
Gordius# show conf … interface ATM0/0 description conexion
fisica OC3 conmutador ATM no ip address atm sonet stm-1 atm pvc 1
0 5 qsaal 155000 155000 94 atm pvc 2 0 16 ilmi 155000 155000 94 !
interface ATM0/0.1 multipoint description conexion con RedIRIS
para UV (45Mbps) mtu 1500 bandwidth 90000 ip address
130.206.211.1 255.255.255.248 atm pvc 11 1 225 aal5mux ip 55000
55000 32 atm pvc 12 3 58 aal5snap 35000 35000 32 map-group
ip-rediris … map-list ip-rediris ip 130.206.211.2 atm-vc
11 broadcast ip 130.206.211.3 atm-vc 12 broadcast Config. router
gordius del ejemplo anterior VC IP solo (VPI 1/VCI 225) CBR 55
Mb/s Interfaz física OC-3 Circuitos de
señalización e ILMI Subinterfaz ATM
‘Mapeo’ de los VPI/VCI a direcciones IP Subred de
ocho direcciones VC SNAP (VPI 3/VCI 58) CBR 35 Mb/s
Transporte de datagramas IP sobre AAL5 con encapsulado LLC/SNAP
IP LLC/SNAP AAL5 ATM FÍSICA Cabec. IP SNAP Cabec. IP
ConvergenceSublayer (CS) Segmentation & Reassembly (SAR)
Datos Cabec. IP SNAP Transmission Convergence (SONET/SDH, PDH,
…) Medio físico (fibra, cobre, …) CRC,Long Relleno
Datos Datos 20 8 8 0-47 5 5 5 5 5 5 48 48 48 48 48 48 48 48 48 48
48 48 8
RFC 1577 (Classical IP over ATM) Versión
‘mejorada’ de RFC 1483: Mecanismo de
resolución de direcciones: ATM ARP (similar a ARP)
Posibilidad de crear varias redes IP lógicas (LIS, Logical
IP Subnet) sobre una misma red ATM física También
soporta tráfico multiprotocolo pero las mejoras solo
están disponibles para IP Requiere: Utilizar cabecera
LLC/SNAP Soporte de SVCs en la red ATM (protocolo de
señalización). Solo usa categoría de
tráfico UBR (no aprovecha características de
QoS)
ATM ARP En cada LIS (Logical IP Subnet) debe haber un servidor
ATM ARP que mantenga una tabla de equivalencias entre direcciones
IP y ATM. Puede haber mas de uno por razones de fiabilidad. La
tabla se rellena de forma dinámica: cada host al arrancar
se registra enviando un mensaje al servidor ATM ARP. Para saber
la dirección ATM que corresponde a una dirección IP
dada los hosts preguntan al servidor ATMARP; las respuestas las
anotan en una tabla, la cache ATMARP, donde las conservan durante
15 min. Las entradas en el servidor también caducan; los
clientes se deben re-registrar cada 20 minutos También hay
un protocolo ATM ARP Inverso análogo a RARP Los mensajes
ATM ARP y ATM ARP Inverso son muy similares a los de ARP y
RARP.
(Gp:) Servidor ATMARP (Gp:) Configuración: IP:
147.156.12.3 ATM: 39..2c01.00 (Gp:) Tabla ATMARP IP ATM
147.156.12.3 39..2c01.00 (Gp:) Cliente A (Gp:)
Configuración: IP: 147.156.15.7 ATM: 39..579b.00 ARP
Server: 39..2c01.00 Funcionamiento de ATM ARP: registro inicial
(Gp:) El servidor responde con un mensaje ATMARP inverso, es
decir pide la dirección IP que corresponde a la ATM del
cliente (Gp:) 2 (Gp:) Al arrancar A establece un SVC con el
servidor ATMARP y le lanza un mensaje solicitando ser registrado
en su tabla. En el mensaje manda su ATM pero no su IP. (Gp:) 1
(Gp:) 39..579b.00 (Gp:) A responde al mensaje con lo cual el
servidor recopila la información necesaria y la incorpora
en sus tablas (Gp:) 3 (Gp:) 147.156.15.7 Red ATM
ATM ARP: resolución de direcciones Servidor ATMARP Cliente
B Cliente A A llama a B, establece un SVC con él y le
envía el ICMP Echo Request (Gp:) 3 Para responder B ha de
averiguar la dirección ATM de A. Envía un ATMARP
request al servidor preguntándosela (Gp:) 4 A quiere
enviar un ping a B. Lanza un ATMARP request hacia el servidor
preguntando por la dirección ATM de 147.156.30.4. 1 El
servidor responde con la dirección ATM solicitada, con lo
que A añade una entrada en su ATMARP cache (Gp:) 2 (Gp:) 6
B le envía el ICMP Echo Reply a A por el SVC establecido
(Gp:) 5 El servidor responde con la dirección ATM
solicitada IP: 147.156.12.3 ATM: 39..2c01.00 IP: 147.156.15.7
ATM: 39..579b.00 ARP Server: 39..2c01.00 IP: 147.156.30.4 ATM:
39..468a.00 ARP Server: 39..2c01.00 Tabla ATMARP IP ATM
147.156.12.3 39..2c01.00 147.156.15.7 39..579b.00 147.156.30.4
39..468a.00 ATMARP Cache IP ATM 147.156.30.4 39..468a.00 ATMARP
Cache IP ATM 147.156.15.7 39..579b.00
Subredes IP Lógicas (LISes) Permiten formar grupos en una
misma red ATM por razones de gestión, afinidad, seguridad,
etc. También permiten reducir el número de VCs que
se establecen en la red; la comunicación entre miembros de
LISes diferentes se ha de hacer necesariamente a través de
uno o varios routers. En cada LIS ha de haber al menos un
servidor ATMARP. Normalmente cada LIS se corresponde con una
subred IP (como ocurría con las VLANs). En
‘Classical IP over ATM’ no se ha previsto un
mecanismo para la transmisión broadcast/multicast; para
hacerla es preciso que el router establezca un SVC con cada host
y duplique la información.
Organización de LISes en ‘Classical IP over
ATM’ Servidor ATMARP 123.233.45.2 Servidor ATMARP
123.233.77.2 LIS B: 123.233.45.0/24 LIS A: 123.233.77.0/24
123.233.77.1 123.233.45.1 123.233.45.3 123.233.45.12
123.233.45.27 123.233.77.34 123.233.77.86 X Y La
comunicación X-Y pasa dos veces por la red ATM SVCs
Modelo ‘Overlay’ de Classical IP over ATM
ConmutadorATM Host ATM Host ATM ATM física ATM IP OSPF
Transporte ATM física ATM ATM ATM física IP OSPF
Transporte Routing IP ConmutadorATM ATM ATM física ATM
física ATM física PNNI PNNI Routing ATM
Aplicación Aplicación CIPoATM/AAL5
CIPoATM/AAL5
Sumario Protocolo AAL5 de ATM Transmisón de datos en ATM
Transmisión de datos en Frame Relay
Transmisión de datos en Frame Relay Frame Relay es un
servicio de red CONS que incorpora: Traffic shaping/traffic
policing (CIR, EIR, bit DE). Estos los maneja la propia red
Control de congestión (bits BECN, FECN). Estas no suelen
utilizarlas los protocolos de nivel superior Es una
tecnología interesante para la interconexión de
LANs, se adapta bien a la transmisión de datos. Incluye
soporte multiprotocolo. Las funciones de control de
congestión no suelen utilizarse en los protocolos que
utilizan Frame Relay El RFC 1294 (Multiprotocol Interconnect over
Frame Relay) especifica como se acomoda el paquete en la parte de
datos de la trama
Modos de funcionamiento de Frame Relay Admite dos modos de
funcionamiento: Tramas enrutadas (routed frames): el paquete de
nivel de red se acomoda en el campo datos de la trama F.R. Una
cabecera adicional indica el protocolo utilizado a nivel de red
(IP por ejemplo) Tramas puenteadas (bridged frames): se transmite
la trama MAC. Una cabecera adicional indica el tipo de trama MAC
(802.3, 802.5, etc.). En este caso los routers que establecen el
circuito F. R. actúan como puentes remotos. Las tramas
puenteadas permiten un funcionamiento más transparente,
pero menos eficiente (tráfico broadcast/multicast)
Datos sobre Frame Relay Router Router Frame Relay Puente remoto
transparente Puente remoto transparente Frame Relay Tramas
puenteadas Tramas enrutadas IP IP IP IP Datagrama IP o ATalk
Trama Ethernet VC VC ATalk ATalk ATalk ATalk
Formato de las Tramas Puenteadas Trama Ethernet en F. R.: 1 2-4 2
1 0-8188 1 2-4 2 1 64-1518 3 2 1 1 1 ‘080C2’ indica
trama puenteada ‘0001’ indica trama Ethernet con CRC
Cabecera LLC/SNAP
Tramas Enrutadas: Datagrama IP en F. R.: Datagrama AppleTalk en
F.R.: 1 2-4 2 1 0-8188 1 2-4 2 1 0-8186 1 1 2-4 2 1 0-8180 3 2 1
1 1 1 ‘CC’ Indica protocolo IP ‘089B’
Indica protocolo AppleTalk
Resolución de direcciones en Frame Relay La
correspondencia entre DLCI y dirección IP se puede
resolver: De forma estática, por configuración de
los equipos. Complicado en grandes redes. De forma
dinámica: mediante algún protocolo de
resolución de direcciones. Se puede utilizar ARP, RARP e
Inverse ARP.
Resolución de direcciones en Frame Relay ARP y RARP
funcionan como en LANs, pero en lugar de la dirección MAC
utilizan el DLCI que obtienen de la cabecera F.R. Requieren
simular envíos broadcast, enviando mensajes (ARP request
p. ej.) a todos los DLCI existentes. Poco eficiente. Para
evitarlo se ha creado Inverse ARP. No hay mensajes broadcast. El
host o router pregunta por cada DLCI quien está
detrás
2.0.0.1/24 2.0.0.4/24 2.0.0.3/24 2.0.0.2/24 DLCI 20 DLCI 30 DLCI
40 Funcionamiento de ARP en Frame Relay A B C D ARP Cache 12
mensajes Red formada por un router principal y tres
satélites, todos ellos en la red 2.0.0.0/24 ARP Req. (A):
¿Quién es la IP 2.0.0.2? ARP Reply (B): Es DLCI 20
ARP Req. (A): ¿Quién es la IP 2.0.0.3? ARP Reply
(C): Es DLCI 30 ARP Req. (A): ¿Quién es la IP
2.0.0.4? ARP Reply (D): Es DLCI 40 20 2.0.0.2 30 2.0.0.3 40
2.0.0.4
2.0.0.1/24 2.0.0.4/24 2.0.0.3/24 2.0.0.2/24 DLCI 20 DLCI 30 DLCI
40 Funcionamiento de Inverse ARP en Frame Relay A B C D ARP Cache
6 mensajes InARP Req. (A): ¿Quien está en DLCI 20?
InARP Reply (B): Está la IP 2.0.0.2 InARP Req. (A):
¿Quien está en DLCI 30? InARP Reply (C):
Está la IP 2.0.0.3 InARP Req. (A): ¿Quien
está en DLCI 40? InARP Reply (D): Está la IP
2.0.0.4 20 2.0.0.2 30 2.0.0.3 40 2.0.0.4
Ejercicios
Ejercicio 2 Conexión IP/ATM con AAL5. RFC 1483 sin
encapsulado LLC/SNAP Datagramas de 9000 bytes CLR (Cell Loss
Rate) = 10-3 Calcular eficiencia medida a nivel IP
Ejercicio 2: solución Mensaje AAL5: 9008 bytes (8 bytes
cola AAL5) Ocupa 9008/48 = 187,67 = 188 celdas (16 bytes de
relleno) Si se pierde solo una celda de cada grupo el datagrama
se pierde; la probabilidad de perder una celda en 188 es 188
veces la de perder una celda: 188 * 10-3 = 0,188 La eficiencia
será pues: 1- 0,188 = 0,812 = 81,2 %
Ejercicio 3 Conexión OC-3c ATM (SDH) entre dos hosts con
AAL5; no se usa encapsulado 802.2. Calcular caudal máximo
efectivo y overhead: A nivel ATM A nivel AAL5 A nivel IP A nivel
TCP A nivel de aplicación Los datagramas son de 9180
bytes
Ejercicio 3. solución Datagrama IP: 9180 bytes Segmento
TCP: 9160 bytes Aplicación: 9140 bytes Mensaje AAL5: 9180
+ 8 = 9188 9188/48 = 191,42 = 192 celdas 192 * 48 = 9216 bytes
(9216 – 9188 = 28 de relleno). Eficiencia 48/53 = 0,9057
ATM: Eficiencia 260/270 (trama OC-3c)
Ejercicio 3: solución