Internet 2 Rogelio Montañana, Universidad de Valencia Master de Telemática, Mondragon Unibertsitatea 21 de enero del 2000 . rogelio.montanana@uv.es

Objetivo Explicar las tendencias y aspectos novedosos que desde el punto de vista tecnológico se están desarrollando o utilizando en Internet 2 y otras redes avanzadas del mundo, que están marcando y marcarán la evolución de Internet en los próximos años.

Sumario ¿Que es ‘Internet 2’? ‘Internet 2’ en el nivel físico POS WDM y redes ópticas ‘Internet 2’ en el nivel de red. IPv6 Calidad de servicio( QoS). Diffserv e Intserv Aplicaciones en ‘Internet 2’

¿Qué es Internet 2? Proyecto iniciado en 1996 en EEUU por el UCAID (University Corporation for Advanced Internet Development) para potenciar nuevos desarrollos en Internet, fundamentalmente con redes y aplicaciones de alta velocidad en entornos de I+D. Actualmente engloba 160 universidades, 40 empresas y otras 30 organizaciones. Muy relacionado con Internet 2 esta el proyecto NGI (Next Generation Initiative) promovido por el Gobierno federal de los EEUU Internet 2 no tiene una red propia: sus desarrollos se basan sobre todo en vBNS y Abilene, dos redes de alta velocidad de EEUU. A estas se conectan redes de otros países, entre ellos TEN-155, la red I+D europea.

Topología de Internet2 vBNS Abilene NGIXs C C C C C C GigaPoP GigaPoP ESNet, NREN, Int’l, ... L NGIXs C Abilene C C C GigaPoP GigaPoP GigaPoP C C C C C C

vBNS Backbone Network Map Seattle C Boston National Center for Atmospheric Research Ameritech NAP Cleveland C Chicago C New York City C A C C A C C Sprint NAP Pittsburgh Supercomputing Center C Perryman, MD A San Francisco C Denver C C C National Center for Supercomputing Applications C J Washington, DC MFS NAP Los Angeles J C A C San Diego Supercomputer Center Atlanta C Ascend GRF 400 Cisco 7507 Juniper M40 FORE ASX-1000 NAP DS-3 OC-3C OC-12C OC-48 A C Houston C J

Abilene: previsión primavera 2000 Seattle New York Indianapolis Cleveland Sacramento Denver Denver Washington Kansas City Los Angeles Atlanta Houston Enlaces de 2,5 Gb/s

Nivel físico POS (Packet Over SONET) WDM Breve descripción de SONET/SDH Uso de IP y ATM sobre SONET/SDH POS WDM Funcionamiento. Situación actual. Redes ópticas.

Evolución de TDM. Origen de SONET/SDH PDH (Plesiochronous Digital Hierarchy) ha sido la base de la telefonía desde los años 60, pero tiene varios problemas: Utiliza diferente norma en cada continente: América: T1: 1,544, T2: 6,312, T3: 44,736 Mb/s Europa: E1: 2,048, E2: 8,448, E3: 34,368 Mb/s Japón: T1: 1,544, T2: 6,312, E3: 32,062 Mb/s No aprovecha adecuadamente la transmisión por fibras ópticas. No incorpora mecanismos adecuados de gestión y recuperación de averías. En 1987 se propuso un nuevo sistema TDM con el fin de resolver estos problemas.

SONET/SDH(Synchronous Optical NETwork/Synchronous Digital Hierarchy) SONET es un estándar ANSI (americano), SDH es ITU-T (internacional). Ambos son compatibles Velocidad base SONET: STS-1 (Synchronous Transfer Signal 1); también llamado OC-1 (Optical Carrier 1). STS-n = OC-n = n * 51,84 Mb/s Velocidad base SDH: STM-1 (Synchronous Transfer Module 1). STM-n = n * 155,52 Mb/s Compatibilidad SONET-SDH: STM-n = STS-(3*n) = OC-(3*n) La forma más normal de transmitir datos en SONET/SDH es con ATM. 14

Estructura de tramas STS-1y STM-1 STS-1 (SONET): Matriz de 90 filas x 9 columnas = 810 Bytes = 6480 bits; 6480 x 8000 tramas/s = 51,84 Mb/s STM-1 (SDH) = STS-3 = 3 x STS-1: 90 x 9 x 3 = 2430 Bytes = 19440 bits = 155,52 Mbps Overhead SDH: 10 filas (3+3+3+1) Parte útil: 260 x 9 = 2340 Bytes = 18720 bits = 149,76 Mbps Los enlaces ATM a 155 Mb/s son siempre de 149,76 Mb/s (el resto es overhead de gestión de SDH).

ATM sobre SONET/SDH ATM y AAL5 introduce un overhead mayor que el de SONET/SDH: SDH SONET Caudal físico Caudal ATM Caudal AAL5 Caudal IP típico* STM-0 STS-1 51,84 49,536 44,862 42,057 STM-1 STS-3c 155,52 149,76 135,63 127,15 STM-4 STS-12c 622,08 600,77 544,08 510,07 STM-16 STS-48c 2488,32 2404,8 2177,9 2041,7 STM-64 STS-192c 9953,28 9620,9 8713,2 8168,4 *Calculado para datagramas de 540 bytes

‘En sus inicios las redes IP fueron guiadas por un conjunto reducido de individuos competentes […]. Por el contrario, los estándares ATM están siendo definidos en el Fórum ATM por un gran número de empresas con intereses mutuamente incompatibles, no todas las cuales tienen experiencia en construir y operar redes ATM’. S. Keshav: An Engineering Approach to Computer Networking, 1997

La Internet global, que se basa en IP, representa una vasta y siempre creciente infraestructura no ATM. Para introducirse en este mercado, y proteger la inversión en tecnología Internet, las redes ATM deben interoperar con redes IP. Desgraciadamente, esa interoperabilidad es problemática porque las redes ATM e IP tienen filosofías de diseño fundamentalmente distintas. [...] A la vista de estas diferencias crear una red integrada IP/ATM puede ser un ejercicio frustrante. Aun así, si las redes ATM van a ser utilizadas por la siempre creciente población de usuarios IP, deben acomodar los deseos de estos usuarios. Esto es un reto para los diseñadores de los protocolos ATM. S. Keshav: 'An Engineering Approach to Computer Networking‘, 1997

POS (Packet Over SONET, o PPP Over SONET) El uso de IP over ATM/AAL5 introduce un overhead medio del 14,5% (datagramas de 540 bytes). Usando PPP (Point to Point Protocol) el overhead se reduce al 1%. PPP over SONET/SDH está estandarizado en el RFC 1619 (5/1994) y en RFC 2615 (6/99). Al suprimir la capa ATM perdemos capacidad de gestión y multiplexación. P. Ej. no podemos compartir un enlace para tráfico IP y centralitas (habría que pasarlas a VoIP).

IP 122,44 Mb/s AAL5 127,15 Mb/s ATM 135,63 Mb/s SONET/SDH 149,76 Mb/s ÓPTICA 155,52 Mb/s IP 142,37 Mb/s PPP 147,84 Mb/s SONET/SDH 149,76 Mb/s ÓPTICA 155,52 Mb/s IP over ATM POS

POS (Packet Over SONET, o PPP Over SONET) En POS la multiplexación la da SONET/SDH (p. Ej. un enlace STM-4 se divide en cuatro STM-1, tres para IP y uno para ATM. Interesa usar POS cuando: Todo el tráfico es IP La mayor parte del tráfico es IP y el que no lo es se puede encapsular en IP (VoIP). Actualmente POS es de uso habitual en redes SONET/SDH con tráfico IP únicamente, por ejemplo las de los grandes ISPs.

Justificación de WDM A pesar de las altas velocidades (hasta 10 Gb/s) de SONET/SDH algunos operadores no tienen bastante. Además los equipos de 10 Gb/s son muy caros (mas de 4 veces los de 2,5 Gb/s). En esos casos la solución es utilizar varias fibras para la conexión, repartiendo el tráfico Pero no siempre se dispone de fibras libres, y tirar fibras nuevas es también muy caro.

Multiplexación por división en longitudes de onda (WDM) La multiplexación por división de longitudes de onda o WDM (Wavelength Division Multiplexing) consiste en enviar varias señales a diferentes longitudes de onda (diferentes ) por una misma fibra (luz de varios ‘colores’) Cuando se utilizan muchas  (8 o más) se llama DWDM (Dense WDM)

WDM La fibra óptica no es igualmente transparente a todas las  (longitudes de onda); hay tres ‘ventanas’ en las que es más transparente: Ventana  (nm) Atenuac. (dB/Km) Alcance max. (Km) Costo opto-electrónica Usos 1ª 850 2,3 2 Bajo LAN 2ª 1310 0,5 40 Medio LAN, WAN, SONET 3ª 1550 0,25 160 Elevado WAN, SONET

Atenuación de la fibra óptica en función de la longitud de onda Primera ventana Segunda ventana Tercera ventana OH- OH-   OH-  Atenuación de la fibra óptica en función de la longitud de onda Los picos corresponden a absorción producida por el ión hidroxilo, OH-

Evolución de WDM  Generación Ventana Número de  Separación (nm) 2ª y 3ª 2 240 2ª (WDM) 3ª 2-4 8-16 3ª (DWDM) 4ª (DWDM) 40-160 0,2-0,8 Estado Actual 

WDM Cuando una señal óptica se transmite a distancia es preciso regenerarla cada cierto tiempo. La regeneración puede ser analógica (amplificador óptico) o digital (repetidor); en este caso hay que convertirla primero en señal eléctrica: Óptica-> eléctrica -> repetidor -> eléctrica->óptica Con WDM es fundamental que el amplificador óptico tenga un comportamiento lo más lineal posible en todo el rango de . De lo contrario habrá que recurrir a poner más repetidores.

DWDM DWDM ha sido posible gracias a la aparición de amplificadores ópticos muy lineales en todo el rango de la 3ª vent. Estos dispositivos tienen pequeñas cantidades de erbio (metal usado en algunas aleaciones); por ello estos amplificadores se denominan EDFAs (Erbium Doped Fiber Amplifiers).

Ganancia típica de un EDFA en la 3ª ventana

Esquema de un EDFA típico Se amplifican todas las  en 3ª ventana simultáneamente Parámetros importantes: linearidad de la ganancia, ruido, nivel de saturación, ancho de banda

WDM Los EDFA permiten amplificar la señal óptica en ruta sin tener que convertirla en señal eléctrica. Esto reduce mucho el costo de WDM. En la práctica cada 5-6 amplificadores hay que poner un repetidor para regenerar la señal. Las limitaciones físicas de WDM son proporcionales al cuadrado de la velocidad; por esto es mas normal usar enlaces OC-48 (2,5 Gb/s) que OC-192 (10 Gb/s)

Esquema funcional de una conexión WDM Multiplexor Desmultiplexor

Uso de WDM/DWDM/CWDM Actualmente DWDM se utiliza en enlaces de largo alcance y gran capacidad, porque es donde sale más rentable. Existen multiplexores de bajo costo (2 Mpts) que permiten WDM de 4 , llamada CWDM (Coarse WDM). Esto permite diseñar LANS con WDM (ver por ejemplo www.nbase.com). A medida que la tecnología avance irán apareciendo equipos similares de más .

DWDM Hoy en día hay sistemas DWDM que transmiten: Y también: 40  * OC-48 (2,5 Gb/s) = 99,5 Gb/s 16  * OC-192 (10 Gb/s) = 159 Gb/s 40  * OC-192 (10 Gb/s) = 398 Gb/s Y también: 160  * OC-192 = 1,59 Tb/s Con un equipo así se podrían mantener 12,5 millones de videoconferencias por un solo par de fibras simultáneamente.

Red GTS (Global TeleSystems Group) www.gtsgroup.com Utiliza infraestructura de ferrorcarriles en Europa

Red IP de GTS Enlaces SDH STM-16 (2,5 Gb/s) con POS Múltiples STM-16 por fibra con DWDM

Redes Ópticas Mediante WDM se puede asignar al usuario una  y enrutarla conmutando de forma estática, manejándola como si fuera un PVC de ATM. Los equipos que permiten cambiar la  en ruta se denominan cross-connect ópticos y cumplen una función parecida a los cross-connect de SDH. Esto aún no está estandarizado. Con multiplexores y conmutadores ópticos es posible montar IP/PPP directamente sobre la fibra suprimiendo la capa SONET/SDH, con lo que se reduce aún más el overhead.

Alternativas de transporte IP AAL5 ATM SONET/SDH ÓPTICA IP PPP SONET/SDH ÓPTICA IP PPP ÓPTICA IP over ATM POS/SONET POS/Óptica

Redes Ópticas El verdadero atractivo de WDM será cuando sea posible realizar la conmutación óptica de paquetes. Esto está ‘a la vuelta de la esquina’. Actualmente ya es posible hacer buffering óptico de paquetes. Ejemplo: proyecto europeo KEOPS (Keys to Optical Packet Switching): www.intec.rug.ac.be/Research/Projects/horizon/projects/keops/keops.html

CA*net 3 National Optical Internet Consortium Partners: Bell Nexxia Nortel Cisco JDS Uniphase Newbridge CA*net 3 Primary Route CA*net 3 Diverse Route GigaPOP ORAN Deploying a 4 channel CWDM Gigabit Ethernet network – 700 km Deploying a 4 channel Gigabit Ethernet transparent optical DWDM– 1500 km Condo Dark Fiber Networks connecting universities and schools Multiple Customer Owned Dark Fiber Networks connecting universities and schools Netera SRnet MRnet BCnet ACORN St. John’s Calgary Regina Winnipeg ONet RISQ Charlottetown Fredericton Vancouver 16 channel DWDM -8 wavelengths @OC-192 reserved for CANARIE -8 wavelengths for carrier and other customers Montreal Halifax Ottawa Seattle STAR TAP Toronto Los Angeles Chicago New York 10 10 9 10 9 9 10 10 10 10 10 10 10

Redes avanzadas Internet 2: www.internet2.edu Abilene (USA): www.ucaid.edu/abilene/ vBNS (USA): www.vbns.net NTON (Natl. Transp. Optical Network, USA): www.ntonc.org CA*net3 (Canadá): www.canet2.net GTS: www.gtsgroup.com Gigabit testbed (Alemania): www.dfn.de/projekte/gigabit/ Gigaport (Holanda): www.gigaport.nl Redes europeas de I+D: www.dante.org.uk/ten-34/nn-high-speed.html

Sumario ¿Que es ‘Internet 2’? ‘Internet 2’ en el nivel físico POS WDM y redes ópticas ‘Internet 2’ en el nivel de red. IPv6 Calidad de servicio( QoS). RSVP/Intserv DiffServ

Protocolo IPv6 Desarrollado fundamentalmente para resolver el problema de escasez de direcciones de IPv4 De paso se incorporaron mejoras en seguridad, eficiencia, calidad de servicio, tráfico multicast, etc. 6Bone (IPv6 Backbone) Red experimental a nivel mundial (desde 1996) Actualmente no está claro para cuando será mayoritario el uso de IPv6

Ventajas de IPv6 Direcciones. Pasa a direcciones de 128 bits. Eficiencia. Simplifica cabeceras. Reduce tablas de routing. Seguridad. Incorpora mecanismos de privacidad y validación mediante criptografía Calidad de Servicio. Previsto soporte de tráfico en tiempo real. Multicast. Mejora soporte. Movilidad. Permite movilidad manteniendo dirección. Sencillez: posibilidad de autoconfiguración de equipos Evolución. Contempla mecanismo para futuras opciones. Compatibilidad: puede coexistir con IPv4

Direcciones IPv6 Dirección de 16 bytes en decimal (IPv4): 128.0.0.0.0.0.0.0.1.35.69.103.137.171.205.239 La misma en hexadecimal (IPv6): 8000:0000:0000:0000:0123:4567:89AB:CDEF  Los ceros a la izquierda pueden omitirse y si uno o más grupos tienen todo ceros se pueden abreviar poniendo dobles dos puntos:   8000::123:4567:89AB:CDEF Para direcciones IPv4 se puede usar la notación decimal con puntos: ::147.156.11.11

Cabecera IPv6 (según RFC 1883)

Principales cambios de IPv6 Autoconfiguración y movilidad: el host asigna los 6 últimos bytes (dir. MAC) y toma los 10 primeros del router. Eficiencia: se suprime el checksum Opciones: el campo de opciones se reemplaza por el de Siguiente cabecera; esto simplifica el proceso en cada router y da un mecanismo de extensión de opciones. El campo etiqueta de flujo pretende identificar flujos que necesiten Calidad de Servicio, pero no ha sido desarrollado.

Situación actual de IPv6 Existe una red experimental a nivel mundial (6bone) desde 1995. Las principales redes académicas del mundo participan en dicha red experimental. Los fabricantes y los ISPs han mostrado poco (o nulo) interés por IPv6. Decepción respecto a las expectativas que había en 1995-96. La mayoría de las mejoras de IPv6 se han incorporado por un proceso evolutivo en IPv4

Cambios recientes en IPv4 Direcciones: uso de NAT (Network Address Translation), Proxies y Cortafuegos, con reducción drástica en la demanda de direcciones públicas (RFC 1918). Eficiencia: uso de CIDR para reducir tablas en routers del ‘core’ (RFC 1817, 8/1995) Seguridad: IPSEC (RFC 2410, 11/1998). Calidad de Servicio: estandarización de Intserv y Diffserv Multicast: control administrativo de ámbito (como en IPv6): RFC2365 (7/1998) Movilidad: DHCP (RFC 1534) y soluciones propietarias Sencillez (autoconfiguración): DHCP

RFCs y referencias de IPv6 Obsolteo: RFC 1883 (12/1995) (campo Prioridad) Vigente: RFC 2460 (12/1998) (campo Clase De Tráfico) Web de 6Bone: 6bone.net

Calidad de Servicio en Internet “El Santo Grial de las redes de computadores es diseñar una red que tenga la flexibilidad y el bajo costo de la Internet, pero que ofrezca las garantías de calidad de servicio extremo a extremo de la red telefónica.” S. Keshav: 'An Engineering Approach to Computer Networking‘, 1997

Calidad de Servicio (QoS) Ejemplos de parámetros de Calidad de Servicio: Capacidad mínima (Mb/s) Retardo máximo (ms) Fluctuación máxima del retardo o ‘jitter’ (ms) Paquetes perdidos máximo (%) Si se garantiza(n) alguno(s) de esos parámetros decimos que la red ofrece ‘calidad de servicio’ o QoS (Quality of Service); de lo contrario decimos que es una red con servicio ‘best effort’.

Retardo y “Jitter” D3 = D2 Emisor Receptor Red A B C t A B C D1 Emisor Transmite t A B C Receptor Recibe D1 D2 = D1 D3 = D2 t

Congestión y Calidad de Servicio Sería muy fácil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello habría que sobredimensionar todos los enlaces, cosa no siempre posible o deseable. Prácticamente cualquier red sufre alguna vez congestión. Para dar QoS en esos casos es preciso tener mecanismos que permitan dar un trato distinto al tráfico preferente y cumplir lo prometido, también llamado SLA (Service Level Agreement).

Calidad de Servicio Vídeoconferencia Aprendizaje a Distancia Aplicaciones críticas Tráfico best effort Voz Transfer. De fichero, E-Mail

Calidad de Servicio en Internet La congestión es el principal problema de la Internet actual. TCP/IP fue diseñado para dar un servicio ‘best effort’ solamente Existen aplicaciones que no pueden funcionar con best-effort. Ej.: videoconferencia, VoIP (Voice Over IP), etc. Se han hecho modificaciones a IP para que pueda funcionar como una red con QoS

Calidad de Servicio: Reserva o Prioridad Existen dos posibles estrategias para dar trato preferente a un usuario en una red: Carril BUS, es decir reservar capacidad para su uso exclusivo. A veces se denomina ‘QoS hard’ Ambulancia, o sea darle mayor prioridad que a otros usuarios. A veces se denomina ‘QoS soft’ Cada una tiene sus ventajas y sus inconvenientes.

¿Reserva o Prioridad? La reserva: La prioridad: Da una garantía casi total Supone un derroche de recursos en algunos casos Requiere que cada nodo intermedio tenga conocimiento de las sesiones activas La prioridad: Basa su garantía en factores estadísticos Permite aprovechar mejor la infraestructura Los nodos intermedios no necesitan conocer las conexiones activas. La reserva de capacidad supone una garantía casi total, ya que la disponibilidad de recursos se comprueba en el momento de solicitar la comunicación y si no es posible la conexión se rechaza. Sin embargo es técnicamente muy compleja de implementar en grandes redes, ya que cada router ha de tomar nota de cada reserva que se realiza a través suyo. Por el contrario la priorización de tráfico basa su garantía en factores estadísticos. Si todo el tráfico que se inyecta en la red es de la máxima prioridad los problemas de congestión ocurrirán igual que antes (algo parecido al jefe que encarga todas las tareas con la máxima urgencia). Para evitar este problema se suele fija un caudal máximo de tráfico prioritario que cada usuario puede inyectar en la red, pero aún así la red normalmente no se diseña para el caso en que cada usuario inyecte el máximo de tráfico prioritario permitido, ya que esto sería muy caro. La priorización es más sencilla de implementar, ya que al no haber un mecanismo de reserva explícito los routers no necesitan conocer que conexiones (por ejemplo videoconferencias) pasan a través suyo, puesto que lo único que han de hacer es ‘colar’ a los paquetes que les lleguen marcados como prioritarios.

Calidad de servicio en Internet En Internet se han desarrollado y estandarizado los dos mecanismos: IntServ (Integrated Services) y protocolo RSVP. El usuario solicita de antemano los recursos que necesita; cada router del trayecto toma medidas para satisfacerle. DiffServ (Differentiated Services). El usuario solicita un determinado nivel de prioridad; los routers van agregando las demandas de los usuarios y propagándolas por el trayecto. Esto le da al usuario una confianza razonable de conseguir la QoS solicitada. Ambos mecanismos son compatibles Aunque el protocolo RSVP y el modelo IntServ se especificaron hace ya varios años, su uso se ha limitado a experiencias piloto y no se ha extendido entre los fabricantes y por ende entre los proveedores de servicios Internet. En cambio DiffServ y el mecanismo de prioridades, a pesar de ser más reciente, ya está funcionado en varios proveedores de servicios Internet. La razón principal para la acogida de DiffServ y el abandono de IntServ son las ventajas expuestas en la transparencia anterior, y sobre todo el problema que supone técnicamente la necesidad de que en una conexión RSVP cada router del trayecto tome nota de la conexión. En los routers del backbone de Internet esto supone mantener tablas con miles de entradas, que se han de estar actualizando constantemente. Ningún fabricante de routers ha podido (o ha querido) desarrollar una implementación eficiente de RSVP que permita satisfacer este requerimiento.

Tipos de aplicaciones en IntServ Tolerantes Intolerantes Elásticas Datos UDP Datos TCP Tiempo Real Multimedia Emulación de circuitos

Tipos de servicio en ‘Integrated Services’ Servicio ‘Best Effort’: ninguna garantía Servicio ‘Controlled-Load’: calidad similar al de una red de datagramas poco cargada. Servicio Garantizado: Da garantías de caudal y retardo. Cada elemento en la ruta debe dar garantías. A veces no puede implementarse (ej. Ethernet compartida)

Reparto de recursos en Servicios Integrados Best Effort Caudal  Carga controlada Garantizado Tiempo 

Que es RSVP? RSVP =Resource reSerVation Protocol Reserva la capacidad solicitada en todos los routers del camino. Es un protocolo de señalización, como el utilizado para establecer un SVC ATM o una llamada telefónica. Pensado principalmente para tráfico multicast No es un protocolo de routing

Como funciona RSVP Cada router del trayecto que implementa RSVP incluye cuatro elementos: Admission Control: comprueba si la red tiene los recursos suficientes para satisfacer la peticion. Policy Control: determina si el usuario tiene los permisos adecuados para la petición realizada. Packet Classifier: clasifica los paquetes en categorías de acuerdo con la QoS a la que pertenecen. Packet Scheduler: organiza el envío de paquetes dentro de cada categoría.

Funcionamiento de RSVP en Multicast Emisor Funcionamiento de RSVP en Multicast 1,5 Mb/s Las reservas se agregan a medida que ascienden en el árbol multicast. 1,5 Mb/s 1,5 Mb/s 1,5 Mb/s 1,5 Mb/s Receptor Receptor Receptor

RSVP (Cont.) RSVP reserva la capacidad solicitada en todos los routers del camino. Es un protocolo de señalización, como el utilizado en una conexión ATM o llamada telefónica. Cada router ha de mantener el detalle de todas las conexiones activas que pasan por el, y los recursos que cada una ha reservado. El router mantiene información de estado sobre cada flujo. Si no se pueden asegurar las condiciones pedidas se rechaza la llamada

Concepto de flujo Un flujo es un tráfico continuo de datagramas relacionadosque se produce como resultado de una acción del usuario y requiere la misma QoS Un flujo es simplex (unidireccional) Un flujo es la entidad más pequeña a la que los routers pueden aplicar una determinada QoS Por ejemplo una videoconferencia podría estar formada por dos flujos, uno para el audio y otro para el vídeo. Los flujos pueden agruparse en clases; todos los flujos dentro de una clase reciben la misma QoS.

Identificación de flujos Para realizar la reserva cada router del trayecto ha de identificar los datagramas correspondientes al flujo para el que se ha hecho la reserva. En IPv4 dicha identificación se realiza a partir de las direcciones de origen y destino y el número de puerto (TCP o UDP) de origen y destino . En IPv6 la identificación puede hacerse como en IPv4 o alternativamente usando el campo ‘etiqueta de flujo’ en vez de los números de puertos. Aún no hay ninguna implementación de RSVP que utilice la etiqueta de flujo.

Problemas de IntServ/RSVP RSVP produjo una euforia inicial (1996-1997) que luego dio paso a decepción. La razón principal fueron problemas de escalabilidad. La necesidad de mantener información de estado en cada router hace inviable usar RSVP en el ‘core’ de Internet. No está claro como obtienen los routers la información necesaria para el módulo ‘Policy Control’. De nuevo no parece viable que cada router del trayecto tenga que realizar la comprobación para cada flujo.

Problema de escalabilidad de RSVP Muchos flujos Los routers principales han de mantener información sobre gran cantidad de flujos.

Problemas de IntServ/RSVP En emisiones multicast, ¿cuál de los receptores se emplea para efectuar el Policy Control en la parte común del árbol? ¿A quien se le factura el servicio en esa parte? Los fabricantes de routers no han desarrollado implementaciones eficientes de RSVP, debido a sus problemas y al elevado costo. A pesar de todo RSVP/IntServ puede desempeñar un papel en la red de acceso, donde los enlaces son de baja capacidad y los routers soportan pocos flujos.

RFCs IntServ/RSVP Arquitectura IntServ: RFC 1633 (6/1994). RSVP: RFC 2205 (9/1997). Uso de RSVP con IntServ: RFC 2210 (9/1997). Servicio de carga controlada: RFC 2211 (9/1997). Servicio Garantizado: RFC 2212 (9/1997). RSVP e IntServ en ATM: RFC 2382 (8/1998). IntServ en redes de baja velocidad: RFC 2688 y RFC 2689 (9/1999).

Tipos de Servicio en ‘Differentiated Services’ Servicio ‘Best Effort’ básico (sin prioridad). Servicio ‘Best Effort’ con prioridad Servicio ‘Assured Forwarding’: similar a ‘Controlled Load’ (red de datagramas poco cargada). Varios niveles de prioridad posibles. Servicio ‘Expedited Forwarding’ o ’Premium’: similar al servicio garantizado de IntServ. Equivale al CBR de ATM (línea dedicada).

Reparto de recursos en Servicios Diferenciados Best Effort Caudal  Assured Forwarding Expedited Forwarding (Premium) Tiempo 

DiffServ En vez de distinguir flujos individuales clasifica los paquetes en categorías (según el tipo de servicio solicitado). Los usuarios pueden contratar o solicitar un determinado caudal en una categoría dada. Los routers tratan cada paquete según su categoría (que se especifica en la cabecera del paquete). El Policy Control/Admission Control sólo se ha de efectuar en los routers de entrada a la red y en los que atraviesan fronteras entre redes diferentes.

DiffServ La información necesaria para aplicar el Policy Control y Administrative Control es mantenida para toda la red por un elemento denominado el Bandwidth Broker (BB). El BB es el encargado de realizar todos los controles administrativos y gestionar los recursos de red disponibles. El BB puede intercambiar información con otros BB de otras redes. Los ISPs pueden acordar políticas de intercambio mutuo.

Arquitectura DiffServ Bandwidth Brokers (realizan control de admisión, gestionan recursos de red, configuran routers periféricos y fronterizos) Destino Origen BB BB Routers ‘core’ Routers ‘core’ Router fronterizo entrante (classificar, controlar, marcar aggregados) Router fronterizo saliente (dosificar agregados) Router periférico (controlar, marcar flujos)

Modelo DiffServ (DS) Las categorías de Diffserv se identifican mediante el campo DS: | | DS|CP | | C|U DSCP: Differentiated Services CodePoint CU (Currently Unused):reservado para usos futuros En IPv4 el campo DS susutituye al Tipo de Servicio. En IPv6 se amplió el campo Prioridad de 4 a 8 bits (RFC 2470) y se le cambió el nombre a Tipo de Tráfico.

Cabecera IPv6 con campo DS

Modelo DiffServ (DS) Con 6 bits en el campo DS se pueden tener hasta 64 ‘codepoints’ (categorías de tráfico) diferentes. De momento se han dividido en 3 grupos: xxxxx0 Uso estándar (32 valores) xxxx11 Uso Local/experimental (16 valores) xxxx01 Reservado (16 valores) En el grupo estándar los tres primeros bits indican la clase

111110 Reservado (routing) 111100 111010 111000 110110 110100 110010 110000 101110 Expedited (Premium) 101100 101010 101000 100110 Assured Clase 4 Preced. Alta 100100 Assured Clase 4 Preced. Media 100010 Assured Clase 4 Preced. Baja 100000 011110 Assured Clase 3 Preced. Alta 011100 Assured Clase 3 Preced. Media 011010 Assured Clase 3 Preced. Baja 011000 010110 Assured Clase 2 Preced. Alta 010100 Assured Clase 2 Preced. Media 010010 Assured Clase 2 Preced. Baja 010000 001110 Assured Clase 1 Preced. Alta 001100 Assured Clase 1 Preced. Media 001010 Assured Clase 1 Preced. Baja 001000 000110 000100 000010 000000 Best Effort (default) Valores estándar del campo DS. Los no especificados son configurables por el usuario

RFCs Modelo Diffserv Definición campo DS: RFC 2474 (12/1998). Arquitectura DiffServ: RFC 2475 (12/1998). ‘Per Hop Behavior’: RFC 2597 y RFC 2598 (6/1999).

IntServ vs DiffServ IntServ fue desarrollado con anterioridad a DiffServ. Sin embargo DiffServ se ha extendido mucho más que IntServ DiffServ permite agregar flujos, de forma que el modelo es escalable. Debido a estas diferencias muchos fabricantes de routers implementan versiones eficientes de DiffServ, pero no de IntServ. Actualmente muchos ISP implementan DiffServ. Qbone (red expermiental de QoS en Internet 2) ha decidido seguir el modelo DiffServ.

RSVP vs DiffServ RSVP DiffServ Información por flujo en cada router Problemas de escalabilidad Énfasis en multicast DiffServ BB BB Cada red tiene un BB que gestiona sus recursos Recursos controlados en punto de acceso Paquetes clasificados por categorías Enfocado a tráfico agregado, no a flujos

Combinación de RSVP y DiffServ En la periferia de la red el uso de RSVP no plantea problemas y puede ser necesaria la reserva estricta de recursos. En este caso el router que conecta con el core ‘traducirá’ la petición al servicio IntServ más parecido.

Referencias QoS Intserv:www.ietf.org/html_charters/intserv-charter.html. RSVP: www.ietf.org/html_charters/rsvp_charter.html. Ver también: www.isi.edu/rsvp/pub.html y www.cisco.com/cpress/cc/td/cpress/fund/ith2nd/it2443.htm Diffserv: www.ietf.org/html_charters/diffserv_charter.html Qbone: www.internet2.edu/qbone/ Grupo de trab. QoS Internet2: www.internet2.edu/qos/wg B. Teitelbaum: ‘Internet 2 Qbone: A Test Bed for Differentiated Services’, www.isoc.org/inet99/proceedings/4f/4f_1.htm Proyecto Quantum: www.dante.net/quantum

Redes experimentales en Internet Experimento Inicio MBone Routing Multicast 1992 6Bone Protocolo IPv6 1996 QBone QoS (DiffServ) 1998

Osaka University’s 3 Million Volt Electron Microscope The electron microscope at Osaka University (left) and its control room (right). Photo ©1999 Osaka University.

Remote Operation from San Diego NCMIR Director Mark Ellisman at the "knob box" in the remote control pavilion at UC San Diego, operating the Osaka microscope. Photo ©1999 Osaka University.

3-D Electron Micrograph of Biological Specimen Object making its way from the center to the left-hand edge of the picture is a blood capillary in the 4.5-micrometer thick sample. The dark tree-like object is the Purkinje cell; the branches are called dendrites. Photo ©1999 Osaka University.

Electron Micrograph of 18-8 Stainless Steel Electron micrograph of 18-8 stainless steel studied by Hidehiro Yasuda via the remote link. The horizontal features are a group of dislocations sliding on a slip-plane toward the grain boundary (vertical winglike feature). Photo ©1999 Osaka University.