Arquitecturas 0708

42
Redes y Servicios Telemáticos Curso 2007/08 Arquitectura de redes José Carlos López Ardao

Transcript of Arquitecturas 0708

Page 1: Arquitecturas 0708

Redes y Servicios TelemáticosCurso 2007/08

Arquitectura de redes

José Carlos López Ardao

Page 2: Arquitecturas 0708

2

Modelo de arquitectura genéricoEn cualquier modelo de arquitectura, los distintos niveles pueden agruparse, de forma genérica, en tres partes:

Aplicación: Encargada de los problemas relacionados con los programas de aplicación concretos (servicios telemáticos), que dan servicio a los usuarios. Como es obvio, esta parte es extremo a extremo y sólo reside en los terminales (hosts)

Transporte: Su misión es doble:Facilitar una interfaz de programación común a las aplicaciones (API) para permitir que éstas se comuniquen con otras en sistemas remotos, con independencia de la la Red de Comunicaciones subyacente.Facilitar a las aplicaciones aquella funcionalidad adicional necesaria no presente en la Red de Comunicaciones: La tendencia actual es diseñar redes eficientes con la funcionalidad mínima necesaria. El resto de funcionalidades comunes que puedan necesitar las aplicaciones deben hallarse en los hosts. El caso tradicional y más habitual es el de la fiabilidad extremo a extremo

Red de Comunicaciones: Encargada de los problemas relacionados con la comunicación de datos a bajo nivel: encaminamiento, control de congestión, errores de transmisión, MAC (en el caso de LANs), interfaz física, etc. Es la única parte existente en los nodos de conmutación, aunque obviamente también debe existir en los hosts.

Page 3: Arquitecturas 0708

3

Un problema de comunicación

HOLAC-J

HOLAHOLA

HOLAC-J

C-J HOLA5

C-J HOLA5

C-J HOLA5

7 B

Comprobación Redundancia➜ ERROR!

Memoria llena➜ Descarte!!!

Redundancia y Dir. destino

Nº SecuenciaVence time-out➜ Retransmisión

Vence time-out➜ Retransmisión

⇐ ACK 7 ⇐ ACK 7

C-J HOLA5 9 B

ACK 5

BA

De Carlos@Aa Juan@B

Tx.fiablede A a B

De A a B

C-J HOLA5 7 B C-J HOLA5 7 B9 B

Nuevo nº secuencia

C-J HOLA5 9 B C-J HOLA5 9 B

De A

OK De A

De Carlos@A

Page 4: Arquitecturas 0708

4

Un problema de comunicación

HOLAC-J

HOLAHOLA

HOLAC-J

C-J HOLA5 C-J HOLA5

C-J HOLA5 9 B

BA

De Carlos@Aa Juan@B

Tx.fiablede A a B

De A a B De A

OK De A

De Carlos@A

C-J HOLA5 9 BC-J HOLA5 9 BC-J HOLA5 9 B

Page 5: Arquitecturas 0708

5

El modelo de arquitectura OSIEn 1983, ISO (International Standards Organization) y CCITT (ahora ITU-T) publican el Modelo de Referencia OSI (Open SystemsInterconnection), con el objetivo de servir como modelo de arquitectura normalizado en el diseño y desarrollo de redes y servicios telemáticos.

Aunque el objetivo de OSI no fue nunca la definición o detalle de protocolos, los escasos protocolos desarrollados conformes a OSItuvieron una repercusión bastante limitada (prácticamente nula en la actualidad). Las razones son simples:

OSI no ha podido nunca con TCP/IP: El crecimiento de Internet y TCP/IP se disparó en 1993 con el WWW, atrayendo a millones de usuarios de todos los ámbitos (100K en 1980, 30M en 1994 y 800M hoy)

Los grandes fabricantes (IBM y DEC) se niegan a abandonar su porción del mercado (bancos y grandes compañías), manteniendo actualmente una todavía considerable base instalada de arquitecturas SNA y DECNET. Sus esfuerzos se centraron en permitir la interoperabilidad entre sus arquitecturas y TCP/IP y nunca en migrar a OSI

No obstante, OSI representa el único esfuerzo realizado en definir, especificar y normalizar completamente un modelo de arquitectura. Por ello, su terminología y algunas de sus ideas son habitualmente utilizadas por los diseñadores y desarrolladores de protocolos de comunicaciones

Page 6: Arquitecturas 0708

6

Terminología de arquitecturas de red (I)Entidad: Elemento software (proceso) o hardware (tarjeta, chip) que se comunica con otros análogos (del mismo nivel) siguiendo las reglas y formatos de un protocolo ⇒ Comunicación horizontal

Servicio: Es la funcionalidad ofrecida al nivel superior, objetivo de la comunicación horizontal

Para que dos entidades se puedan comunicar horizontalmentedeben hacerlo, a su vez, mediante el servicio ofrecido por el nivel inferior ⇒ Comunicación vertical

Este concepto se extiende hasta alcanzar el nivel más bajo (nivel físico), encargado de la simple transmisión de bits

La comunicación vertical se realiza a través de la interfaz definida mediante las primitivas del servicio (que pueden verse como un tipo especial de llamadas al sistema con parámetros)

Las entidades usuarias de un servicio se identifican ante el proveedor mediante el punto de acceso al servicio (SAP)

Page 7: Arquitecturas 0708

7

Un problema de comunicación

HOLAC-J

HOLAHOLA

HOLAC-J

C-J HOLA5 C-J HOLA5

C-J HOLA5 9 B

BA

De Carlos@Aa Juan@B

Tx.fiablede A a B

De A a B De A

OK De A

De Carlos@A

C-J HOLA5 9 BC-J HOLA5 9 BC-J HOLA5 9 B

Comunicación horizontal (“virtual”) ➜ Protocolo

Comunicación vertical (“real”) ➜ Interfaz

Page 8: Arquitecturas 0708

8

Proveedor del servicio de nivel N

Comunicación entre usuario y proveedor de un servicio de nivel N

Nivel N+1

Nivel N

(N+1)-PDU

(N+1)-PDUCabecera

N-PDU

(N+1)-PDU

(N+1)-PDUCabecera

N-PDUProtocolo nivel N

InterfazN-SAP N-SAP

Protocolo nivel N+1

+ ICI+ ICI

N-SDUN-SDU

El protocolo regula el intercambio “horizontal” de PDUs (Protocol Data Units) entre entidades análogasLa interfaz del servicio define el intercambio “vertical” de SDUs (Service Data Units) entre la entidad usuaria y la proveedora del servicioUna PDU consta del campo de datos (SDU recibida del nivel superior) más una cabecera (información de control del protocolo) que consta, en parte, de información de control de la interfaz pasada desde el nivel superior (el SAP destino, por ejemplo)La entidad remota procesa la cabecera de la PDU recibida para ejecutar el protocolo y, si procede, entregar la SDU (el campo de datos) a la entidad de nivel superior identificada por el SAP destino contenido en la cabecera

Page 9: Arquitecturas 0708

9

Terminología de arquitecturas de red: Resumen

Servicio: Define la funcionalidad que una entidad de cierto nivel espera recibir de otra entidad proveedora del nivel inferior

Interfaz del servicio: Define y regula el intercambio “vertical” de datos (SDUs) e información de control entre una entidad usuaria y otra entidad proveedora del nivel inferior.

Protocolo: Define el formato y la secuencia de mensajes (PDUs) intercambiados “horizontalmente”entre dos entidades análogas para dar el servicio esperado, así como las acciones que se deben tomar tras el envío/recepción de un mensaje u otro evento. La PDU comprende la SDU recibida del nivel superior (comúnmente, los “datos”) y la información de control del protocolo (comúnmente, “cabecera” o “overhead”)

Page 10: Arquitecturas 0708

10

Encapsulado de PDUsUn protocolo no interpreta ni usa la información contenida en el campo de datos (la PDU del nivel superior). Se dice que la PDU se halla encapsulada en otra PDU de nivel inferior

Una entidad sólo está interesada en la correcta ejecución del servicio de nivel inferior requerido para transferir sus PDUs a otra entidad análoga remota, siendo irrelevantes los detalles de implementación del protocolo

➜ El encapsulado limita el ámbito de dependencias entre niveles adyacentes a:

la definición del servicio y el intercambio de información a través de la interfaz

Page 11: Arquitecturas 0708

11

Los niveles del modelo OSI: Aplicación7.- Aplicación: Protocolos requeridos por aplicaciones que involucran comunicaciones (servicios telemáticos)

transferencia de ficheros (FTP),correo electrónico (SMTP, MIME), terminal virtual o acceso remoto (TELNET),servicio de nombres (DNS), gestión de red (SNMP),WWW (HTTP), etc.

6.- Presentación: Incluye todas las funciones de manipulación de los datos previas a su envío/recepción por parte de las aplicaciones:

Representación datos independiente de la máquinaCriptografía, Compresión, etc.

5.- Sesión: Permite que usuarios en diferentes máquinas establezcan sesiones entre ellos. Las sesiones ofrecen varios servicios como el control del diálogo, o la sincronización de datos (para evitar retransmisiones masivas de datos en caso de pérdida de la comunicación)

Page 12: Arquitecturas 0708

12

Los niveles del modelo OSI: Transporte

4.- Transporte:Se encarga de facilitar una interfaz común a las aplicaciones (API) que oculta los detalles de la la red de comunicaciones subyacenteAdicionalmente ofrece a las aplicaciones funcionalidad adicional no presente en la red de comunicaciones. Algunas facilidades implementadas tradicional y típicamente en este nivel son:

Fiabilidad extremo a extremoControl del flujoControl de congestión mediante realimentación y control del flujo

Page 13: Arquitecturas 0708

13Los niveles del modelo OSI: Red de comunicaciones

3.- Red: Su misión es controlar la operación de la red de comunicaciones:Direccionamiento global uniformeEncaminamientoControl de congestión en la redFiabilidad extremo a extremo en el caso de una red fiable (actualmente se realiza casi exclusivamente en transporte)

2.- Enlace: Su función básica es transferir paquetes del nivel de Red encapsulados en una trama física (delimitación de trama) sobre un enlace entre dos nodos adyacentes. Se ocupa adicionalmente de la detección (y/o corrección) de errores de transmisión. En el caso de servicio fiable garantiza la transmisión fiable y libre de errores de tramas a través del enlace mediante técnicas ARQ, raras veces usado en enlaces con BER bajas. Si el enlace es compartido (caso de las LANs), OSI asigna las funciones anteriores a un subnivel superior denominado LLC (Logical Link Control ), mientras el control de acceso al medio y el direccionamiento a nivel de enlace son las funciones del nivel inferior denominado MAC (Medium Access Control ).

1.- Físico: Se encarga de la transmisión de bits sobre un canal de comunicación y de los problemas relacionados:

de tipo eléctrico (voltajes, codificación de línea, etc.)de tipo mecánico (conectores)de procedimiento (señales a intercambiar, asignación de pines, etc.)

Page 14: Arquitecturas 0708

14

La arquitectura de Internet (TCP/IP)La arquitectura de Internet (también llamada arquitectura TCP/IP por sus dos principales protocolos) no puede verse realmente como un modelo de arquitectura sino como una colección de protocolos interrelacionadosEn cualquier caso, la arquitectura de Internet admite una representación por niveles:

Aplicación: Se correspondería con los niveles OSI 5 a 7Transporte: La capa OSI fue tomada prácticamente de Internet, donde destacan dos protocolos:

• TCP: fiabilidad extremo a extremo, orientado a flujo• UDP: protocolo simple, no fiable, orientado a mensaje y no secuencial

Red o internet: Equivale básicamente al nivel de Red OSI. Protocolo IPEnlace: La arquitectura de Internet da entera libertad al diseño de la infraestructura de comunicaciones entre entidades IP (hostsy routers), lo que equivaldría al nivel de enlace de OSI. Ésta comunicación puede realizarse no sólo sobre enlaces o LANs de cualquier tipo, sino también sobre otras redes subyacentes (ATM, FR, X.25 o Ethernet conmutada)Físico: Equivalente a OSI

Page 15: Arquitecturas 0708

15

El nivel de enlace en Internet

La tendencia actual en el diseño de redes se centra en concentrar en un único nivel las funciones estrictamente imprescindibles de los niveles 2 y 3 (direccionamiento, encaminamiento, conmutación, detección de errores) dando lugar a la denominada “conmutación de nivel 2”. Ejs.: ATM, Frame-Relay, Ethernet conmutadaDada la preeminencia de IP como protocolo de Red y la omnipresencia de la conmutación de nivel 2, el concepto tradicional del nivel de enlace de OSI ha evolucionado ampliándose para referirse a cualquier tecnología de enlace o red subyacente utilizada para enviar paquetes IPOtros nombres dados al nivel de enlace en Internet son “interfaz de red”, “red subyacente” o “red física” (frente a “red software” como IP)

Page 16: Arquitecturas 0708

16

La arquitectura de Internet (TCP/IP)

Aplicación

Transporte

Red (IP)

Enlace (Red 1)

Físico (Red 1)

Aplicación

Red (IP)

Transporte

Red (IP)

Enlace (Red 2)

Físico (Red 2)

Enlace (Red 1)

Físico (Red 1)

Enlace (Red 2)

Físico (Red 2)

Enlace (Red 1)Físico

(Red 1)

Enlace (Red 2)Físico

(Red 2)

SWITCH SWITCH

RED 1 RED 2

Host A Host BRouter IP

HTTP, SMTP, FTP, etc.

TCP, UDP

IP IP

Page 17: Arquitecturas 0708

17

Direcciones de red y físicasCada interfaz de red en Internet (en un host o router) dispone de dos direcciones únicas:Una dirección física:

Usada para comunicar dos interfaces en la misma red física (LAN o WAN)En el caso de LANs ➜ Direcciones MAC (48 bits)

• Administradas por IEEE: 24 primeros bits asignados a fabricantes que aseguran unicidad

• Grabada por el fabricante del hardware en su ROM ➜ no configurable• Direccionamiento plano (sin estructura jerárquica) ➜ portabilidad (una

tarjeta LAN puede moverse de una LAN a otra)Una dirección de red:

Usada por el protocolo de red (para encaminamiento) y las aplicaciones (para identificación de sistemas finales)En el caso de IP ➜ Direcciones IP (32 bits en IPv4)

• Administradas por ICANN (Internet Corporation for Assigned Names andNumbers): prefijos de longitud variable asignados a sistemas autónomos

• Configurable por el administrador de un sistema autónomo dentro del rango asignado

• Direccionamiento jerárquico (similar a los números de teléfono) ➜ no portabilidad (la dirección IP de una máquina depende en general de la red física en que se ubica)

Analogía: Dir. física es como DNI y dir. de red es como dir. postal

Page 18: Arquitecturas 0708

18

Resolución de direccionesEl paquete IP se ha de enviar en una trama con una dirección física de destino. Dada la dirección IP destino, la entidad IP origen ha de saber a qué dirección física corresponde para solicitar su envío a la red físicaAlgunas soluciones empleadas para resolver el problema de la resolución de direcciones son las siguientes:

Construir manualmente una tabla estática de equivalencias. Ej.: RDSI, X.25, FR, ATMCrear una tabla dinámica que se mantiene de forma automática en un servidor en el que se registra cada equipo. Ej.: ATMEnviar una pregunta broadcast a la red física para localizar al propietario de la dirección de red buscada. Sólo es factible en redes que permiten broadcast, como por ejemplo las LANs. El protocolo usado para ello es ARP (Address Resolution Protocol)

Page 19: Arquitecturas 0708

19

ARP (Address Resolution Protocol)El protocolo ARP (RFC 826) es usado por IP para obtener la dirección física que corresponde a cada dirección IPARP mantiene una tabla caché que contiene la correspondencia entre pares de dirs. IP y física. La tabla también contiene un campo que indica el instante de actualización de cada entrada, de forma que transcurrido cierto tiempo (típico 20 min.) ésta es borrada para permitir reconfiguraciónSi la dirección física buscada no está en la tabla, el cliente ARP intenta comunicarse con el servidor ubicado en la máquina de dicha dirección física:

El cliente envía una trama de difusión (broadcast) sobre la red subyacente (en el caso de LANs, dir. MAC destino todo unos)Si la máquina existe en la red física y el servidor se estáejecutando, éste contesta directamente a la MAC del cliente, facilitándole su propia MAC, la buscada.

Page 20: Arquitecturas 0708

20

http://I2/index.html

Direccionamiento de entidades en Internet:Multiplexación y demultiplexación

M1ETH0

Switch Ethernet

I1

10

6

0x0800

GET index.html

send_TP(I1:TCP(6):10, I2:TCP(6):80, APDU)

IPARP

TCPUDP

HTTP

M2ETH0

I2

80

6

0x0800

IP ARPd

TCP UDP

HTTPd FTPdAPDU (mensaje) ➜

send_IP(I1, I2, TCP(6), TPDU)

8010 APDUTPDU (segmento) ➜

send_eth(M1, M2, 0x800, NPDU)

Segmento TCP (TPDU)NPDU

(paquete) ➜ 6I1I2¿I2?

M2

17 17

0x0806 0x0806

Paquete IP (NPDU)0x800M1M2

Trama Ethernet ➜

21

FTP

recv_TP(&IP_or,&IP_dest,&puerto_or, 80, &APDU)

recv_eth(&MAC_or,&MAC_des,0x800,&NPDU)

recv_IP(&IP_or,&IP_des, TCP(6), &TPDU)

Page 21: Arquitecturas 0708

21Direccionamiento de entidades en Internet:Multiplexación y demultiplexación

Dirección de red IP (única en el mundo) (32 bits IPv4)

Ejs.: 21 FTP, 23 TELNET,25 SMTP, 80 HTTP

Ejs.: 6 TCP, 17 UDP,1 ICMP, 89 OSPF

Dirección de transporte (NSAP)

Socket/Dirección de aplicación (TSAP)

Dir. MAC de 48 bits en LANs(IEEE 802.3,4,5,6,11 y FDDI)

Hasta 8 octetos en IEEE 802.22 octetos en Ethernet

(Ejs.0x0800 IP, 0x0806 ARP)

Protocolo(8 bits)Puerto (16 bits)

Dirección física (única en el mundo) (MAC, ATM, FR, X.25, etc.)

Protocolode red

ARP

Dirección de enlace (LSAP)

Page 22: Arquitecturas 0708

22Direccionamiento de entidades en Internet:Uso de IP y ARP con un router

http://I4/index.html

ETH0

10

6

800h

IPARP

TCP

HTTP

¿I2?

806h

Router IP

M2 M3

I2 I3

ETH0

80

6

0x0800

IPARPd

TCP

HTTPd

0x0806

ETH0 ETH1M1M4

I1 I4

Switch EthernetSwitch Ethernet

Tabla encaminamiento I1Sig. Salto a ➜ Router I2

Tabla encaminamiento RouterSig. Salto a I4 ➜ I4 (ETH1)

6I4I1

ARP ¿I2?0x806FF M1

Tramas Ethernet

Paquete IP ➜ 8010 GET index.html

Paquete IP0x800M2 M1

0x806FF M3

Paquete IP0x800M4 M3

IPARPd

ARP

800h 806h806h 800h

I4

M2

¿I4?

ARP ¿I4?

M4

Tabla encaminamiento I1Sig. Salto a I4 ➜ Router I2

(ETH0)

Page 23: Arquitecturas 0708

23

Tipos de servicios: RepasoDependiendo de la forma en que se accede al servicio a través de la interfaz, éstos se clasifican en servicios orientados a conexión (SOC) y servicios sin conexión (SSC)

Un servicio orientado a conexión (SOC) posee tres fases:Establecimiento de una conexión entre las entidades usuarias remotas, identificadas por sus SAPs.

• Inicialización de la información de estado. • Posible negociación parámetros conexión: tamaños máx. mensajes, QoS esperada, etc. • Posible reserva y asignación de recursos a la conexión

Mantenimiento de la conexión: Transferencia de datos. Al mantenerse información de estado relativa a la conexión, basta con indicar a través de la interfaz el identificador de la conexiónLiberación de la conexión y, si fuera el caso, de los recursos asignados a ésta

Por contra, en un servicio sin conexión (SSC):No se establece conexión alguna. Las unidades de datos son autocontenidas y se envían de forma independiente entre dos SAPs remotosCarece de sentido negociar parámetros o reservar recursos de forma individual para unidades de datos independientesLa ausencia de información de estado obliga a intercambiar a través de la interfaz toda la información de direccionamiento de las entidades origen y destino

Page 24: Arquitecturas 0708

24

Primitivas de servicio

SOCid_conn = listen(&SAP origen, SAP destino)id_conn = connect(SAP origen, SAP destino, opciones conexión)send(id_conn, &datos, long_datos) ...recv(&id_conn, &búfer, long_búfer) ...disconnect(id_conn)

SSCsend(SAP origen, SAP destino, &datos, long_datos, opciones mensaje) ...recv(&SAP origen, SAP destino, &búfer, long_búfer) ...

Page 25: Arquitecturas 0708

El servicio en el nivel de Red

Page 26: Arquitecturas 0708

26

El Servicio del nivel de Red: Repaso

El servicio ofrecido por el nivel de Red al nivel de Transporte debe:

Ser independiente de las redes subyacentesFacilitar a Transporte un esquema de direccionamiento global y uniforme que asegure la unicidad

Habitualmente, el servicio del nivel de Red cuando es SOC (ej. ATM) suele ser también:

SecuencialCon Garantías QoS

Por contra, si el servicio es SSC (ej. IP), suele sertambién:

No secuencialNo garantizado (o best-effort)

Page 27: Arquitecturas 0708

27

Tendencias en el servicio de red: QoS

Atendiendo a queLas restricciones de tiempo real del tráfico multimedia exigen un trato diferenciado por parte de la red que garantice cierto nivel de QoS. Son cada vez más los clientes que están dispuestos a pagar más por recibir garantías de servicio.

⇒ La tendencia actual es que la red ofrezca un servicio con garantías QoS y, por tanto, orientado a conexión

Así, mientras ATM ofrece un SOC con garantías QoS, en IP se está trabajando actualmente para poder incorporar tales garantías y ofrecer un servicio más parecido al SOC: MPLS, RSVP, DiffServ

Page 28: Arquitecturas 0708

28

Tendencias en el servicio de red: No fiabilidad

Independientemente de que el servicio de Red sea SOC o SSC, éste podría ser fiable (entrega garantizada sin errores) o no fiable.

Históricamente el SOC ofrecía también fiabilidad, siendo así mayor la complejidad de la red de comunicaciones (Ej. X.25) y el SSC ofrecía un servicio no fiable, aunque bastante más rápido en general (Ej. IP)

No obstante, la tendencia actual es que la red sólo ofrezca aquella funcionalidad necesaria para cualquier aplicación y tipo de tráfico. Así, mientras para el tráfico de datos tradicional la fiabilidad resultaba imprescindible, no ocurre así con el cada vez más importante tráficomultimedia de tiempo real (audio y vídeo), que si bien posee restricciones temporales severas, ofrece bastante tolerancia a pérdidas

Si además tenemos en cuenta que los medios de transmisión actuales son mucho más fiables (fundamentalmente, la fibra óptica), parece poco conveniente complicar la red de comunicaciones a costa de una pérdida de velocidad y eficiencia, para retransmitir esporádicas pérdidas de paquetes, que tendrían un impacto insignificante en la calidad de la imagen/voz, supuesto que llegasen dentro de plazo.

Por estas razones, en ATM y Frame Relay se ha optado por un SOC no fiable.

Page 29: Arquitecturas 0708

29

El Servicio del nivel de Red: CVs y datagramas

El servicio ofrecido por el nivel de Red (SOC o SSC) es también independiente de su organización interna (CVs o datagramas). Así, las cuatro combinaciones son totalmente factibles

Razonablemente, lo más habitual es ofrecer un SOC con CVs (Ej.: X.25, Frame Relay y ATM) y un SSC con datagramas (Ej.: IP en Internet)

Existen, no obstante, algún caso de SOC sobre red de datagramas, como es el caso de Datapac, por razones de compatibilidad con las normas de acceso X.25

Sin embargo, un SSC sobre CVs no tiene sentido a menos que sean permanentes (PVC), ya que si fuesen conmutados (SVC) supondría una gran ineficiencia el establecimiento y liberación de un CV para enviar cada mensaje. Esta situación se da cuando se usa ATM, X.25 o Frame Relay (que usan internamente CVs) como red subyacente de IP (que ofrece un SSC)

Page 30: Arquitecturas 0708

30

Resumen de protocolos de red: X.25

Las Rec. X.25 propuestas por CCITT (ahora ITU) en 1976, y revisadas por última vez en 1992, normalizan los tres protocolos inferiores en el acceso a las RDPs:

Red (X.25 PLP, Packet Layer Protocol ) Enlace (LAPB, Link Access Procedure Balanced), similar a HDLCFísico (X.21 para interfaces digitales y RS-232 para analógicas)

X.25 PLP ofrece un SOC sobre CVs fiable (implementa control de errores y de flujo extremo a extremo, adicional al que se realiza a nivel de enlace por LAPD)X.25 garantiza una tasa de acceso constante de 64 Kbps. en mensajes de tamaño variable (generalmente hasta 128 bytes). Cabe destacar que X.25 sólo normaliza el acceso, siendo libre el diseño interno de la red aunque, obviamente se vea influenciado por X.25.

Page 31: Arquitecturas 0708

31

Resumen de protocolos de red: Frame Relay (FR)Dadas las grandes limitaciones presentes en X.25 para satisfacer las demandas del tráfico actual, las RDPs se han volcado en la tecnología Frame Relay, cuya arquitectura condensa los protocolos de red y enlace en uno sólo, denominado LAPFLAPF es un protocolo de enlace especial, pues incorpora funciones adicionales típicas de red como la conmutación, direccionamiento y control de congestión, pero eliminando todo el control de errores y flujo tanto a nivel de enlace como extremo a extremoEn resumen, Frame Relay ofrece un SOC no fiablesobre CVs, ofreciendo tasas de acceso que llegan actualmente a los 45 Mbps. en mensajes (tramas) de tamaño variable de hasta 9.000 bytesFrame Relay representa una solución relativamente barata que permite dar acceso de alta velocidad a tráfico de datos que no necesita comunicación en tiempo real

Page 32: Arquitecturas 0708

32

Resumen de protocolos de red: ATMATM es conceptualmente similar a FR:

SOC no fiable sobre CVs en un único protocoloDos diferencias fundamentales con FR:

Mensajes de tamaño fijo (celdas) de 48 bytes de datos, que permiten reducir el jitter y simplificar y acelerar las tareas de conmutaciónATM implementa mecanismos en la red que permitan ofrecer garantías QoS

ATM es la técnica de conmutación en que se basa la RDSI-BA, y hoy en día se ofrecen tasas de acceso que llegan a los Gbps. Para ser usado como red subyacente por debajo de IP debe usarse un protocolo de adaptación entre ambos, siendo el preferido AAL5 sobre PVCs

Page 33: Arquitecturas 0708

33

Red superpuesta (overlay): internetEn su visión más simple y tradicional, una WAN consta de nodos de conmutación (switches) interconectados por enlaces punto a punto.En la práctica, tales enlaces se realizan realmente a través de otras redes (WAN o LAN). Se habla así de una red superpuesta (overlay) o internetsobre otras redes físicas subyacentesEn el caso de Internet, podemos ver a IP como un claro ejemplo de red superpuesta (de ahí su nombre “entre redes”) sobre tecnologías de conmutación de nivel 2 como ATM, FR o Ethernet, cada una de ellas con sus propios esquemas de direccionamiento y encaminamiento, totalmente independientes de los usados en IP.Aunque tanto switches como routers son conceptualmente nodos de conmutación, en la terminología de Internet suelen diferenciarse:

Switches: Nodos de conmutación de nivel 2, que se ocupan del encaminamiento dentro de la red física a la que pertenecen, haciendo uso de las direcciones físicasRouters: Nodos de conmutación de nivel 3 (red o internet, como IP) que se ocupan del encaminamiento extremo a extremo a través de múltiples redes físicas, haciendo uso de las direcciones de red (ej. dirs. IP)

Desde el punto de vista de un protocolo internet como IP, dos máquinas conectadas a una misma red física poseen conexión directa, sea a través de switches o líneas punto a punto, pero no necesitan un router para comunicarseEn definitiva, los routers separan redes físicas, mientras que los switchesforman parte de ellas

Page 34: Arquitecturas 0708

34

Router

Red física

HostSwitch

Page 35: Arquitecturas 0708

35

TúnelesLos routers poseen interfaces físicas con todas las redes físicas que interconectanPara lograr la interconexión entre dos entidades IP en una misma red física, los paquetes IP se encapsulan dentro de los paquetes de la red subyacente, procedimiento denominado túnelDe forma genérica, se dice que un protocolo de red X establece un túnel sobre una red subyacente Y cuando los paquetes de X atraviesan la red Y encapsulados dentro del campo de datos. Ello implicaráadicionalmente resolución de direccionesEjemplos:

Túnel sobre FR/ATM para enviar paquetes IPMBone: túneles multicast sobre redes unicast6Bone: túneles IPv6 sobre redes IPv4

También permiten crear redes privadas virtuales (Virtual Private Networks - VPNs)

Page 36: Arquitecturas 0708

36

Red FR/ATM

Ejemplo de túnel IP sobre FR/ATM

Red IP

RouterEncapsulador Router

Desencapsulador

Datagrama IPPaquete FR/ATM

Red IP

Page 37: Arquitecturas 0708

37

Ejemplo de arquitectura

Page 38: Arquitecturas 0708

38

Nivel de enlace MTU (bytes)PPP (por defecto) 1500PPP bajo retardo 296X.25 (RFC 1356) 1600

Frame Relay (normalmente) 1600Ethernet DIX 1500

Token Ring 4 Mbps 4440AAL5/ATM (por defecto - RFC 1626) 9180

MTU de redes físicasEl nivel 2 (redes físicas o protocolos de enlace) impone un tamaño máximo a los paquetes o tramas que deben cursar, denominado MTU (Maximum Transfer Unit)

Page 39: Arquitecturas 0708

39

Fragmentación a nivel de redSi los paquetes internet sobrepasan la MTU impuesta deben ser divididos en fragmentos, que deben ser recompuestos para entregar el segmento original al nivel de TransporteExisten dos estrategias básicas de fragmentación:

a) Fragmentación transparente: Los fragmentos son recompuestos en cada router para obtener el paquete internetoriginal, con lo que las siguientes redes físicas y routers no son conscientes de tal fragmentación. De esta forma, se puede aprovechar el tamaño máximo de cada red física y aumentar la eficiencia del protocolo. Sin embargo, los fragmentos deben ser encaminados hacia el mismo router, con lo que las decisiones de encaminamiento se ven ligeramente limitadas

b) Fragmentación no transparente: Una vez que un paquete internet es fragmentado, cada fragmento es tratado de forma independiente. La recomposición sólo se realiza en el hostdestino. De esta forma, se puede usar cualquier router de salida, aunque se reduce la eficiencia frente a la fragmentación transparente, pues no se aprovecha la MTU de cada red física atravesada

Page 40: Arquitecturas 0708

40

Tipos de fragmentación

Page 41: Arquitecturas 0708

41

Fragmento elementalLa fragmentación puede dar lugar a problemas de inconsistencia. Por ejemplo, en el caso de redes fiables, las retransmisiones pueden provocar que el destino se encuentre con dos fragmentos con la misma numeración pero distinto tamaño al pasar por routersdistintosPara evitar tales situaciones se usa la técnica del fragmento elemental (FE), consistente en que todos los fragmentos sean del mismo tamaño, lo suficientemente pequeño como para poder atravesar cualquier red física. Así, los fragmentos generados (incluso provenientes de paquetes retransmitidos) serán siempre del mismo tamaño (o menor si es el último).Para mayor eficiencia (datos/[cabeceras+datos]), cada paquete internet contendrá tantos FE como permita el MTU impuesto por cada red física.Para posibilitar la recomposición, la cabecera de un paquete internet debe contener:

un número que identifique al segmento original de Transporte, el número del primer FE contenido en el paquete (es decir, el desplazamiento del paquete actual con respecto al segmento original),y un bit indicando si es el último, es decir, el que contiene el último FE

Page 42: Arquitecturas 0708

42

Ejemplos con fragmento elemental

0