Introduccion A Las Redes de Nueva Genera

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 40

PRESENTADO POR:HENRY VILCA FLOREZ

CODIGO:062106

INTRODUCCIÓN A LAS REDES DE NUEVA


GENERACIÓN

El desarrollo de las tecnologías de telecomunicaciones, se ha reflejado en la tendencia


de integrar todo tipo de servicios en una solo infraestructura de red. Las nuevas
tecnologías IP hacen posible satisfacer los difíciles requerimientos de: acceso,
transporte, control, aplicación y gestión , de las redes tradicionales de comunicación. La
convergencia de redes presenta ciertos inconvenientes como: capacidad, calidad de
servicio, seguridad y fiabilidad. Para das solución a estos problemas han aparecido en el
mercado equipos, técnicas y protocolos que combinados permiten la realización de
modelos de red óptimos.

A esta combinación se conoce como “Modelo de Red de Nueva Generación o Next


Generation Network (NGN)”. La aplicación de este concepto hace posible cambios
significativos como: ahorros, mejoramiento de las capacidades del servicio.

EVOLUCIOÓN EN ENTORNO IP

El desarrollo de las telecomunicaciones ha generado cambios en los modelos de


negocios de muchos operadores y han cambiado el modelo de prestación de servicios.
Se ha pasado de un modelo vertical en el cual la red y los servicios son dependientes
uno del otro, a un modelo vertical intermedio, en donde se mezclan las redes y servicios
de una forma óptima.

El modelo horizontal propone una red común , en la cual los servicios sean transmitidos
por un solo medio, lo que permitirá brindar nuevos servicios, optimizar la red y reducir
costos.
La evolución de las redes tradicionales hacia IP, se ha dado de una forma sincronizada
en la mayoría de los sectores de telecomunicaciones, provocando algunos cambios entre
los cuales tenemos:

 La reducción de costes respecto a la telefonía tradicional.


 Compartir infraestructuras entre los distintos operadores.
 Establecer la convergencia y compatibilidad entre distintas redes.
 La aparición de nuevos servicios.
 La unificación de la gestión, operación y mantenimiento de servicios.

Lo que se pretende es unir en una sola infraestructura las distintas alternativas de


servicios de red y que esta infraestructura pueda responder a estrictos criterios como:
calidad, capacidad, fiabilidad y disponibilidad. En el caso de voz los requerimientos de
calidad son muy altos y se deberán cubrir parámetros de calidad de las redes
tradicionales a consecuencia los usuarios han desarrollado una percepción de calidad
muy elevada a lo largo de los anos de la telefonía tradicional lo que significa un reto
para la soluciones de voz en la Red de Nueva Generación (NGN).

La tendencia observada en los últimos años hacia las soluciones basadas en redes IP,
dentro del modelo ALL-IP, estará condicionado por la necesaria evolución del modelo
de red IP hacia lo que se conoce como la Red de Nueva Generación (NGN).

EL ENTORNO IP EN LA TELEFONÍA MÓVIL.


El sistema UMTS (Universla Mobile Telcommunications System) introduce opciones
en la configuración de la red, arquitectura y protocolos para desplegar una red móvil
basad en IP. Los servicios de paquetes de UMTS ya emplean IP para el transporte de
datos de usuario extremo a extremo, así como el backbone. Además se ha separado la
funcionalidad del MSC (Mobile Switch Center) en dos elementos: el MSC Server y el
Media Gateway. Lo que permite la introducción de un backbone IP en el dominio de
comunicación de circuitos en el núcleo de la red móvil.

Los MSC Server emplearían SS7 sobre IP utilizando soluciones SIGTRAN, mientras
que los Media Gateways transportarían la voz en paquetes empleando tecnología de voz
sobre IP (VoIP).

3GPP especifica una red de acceso de radio UTRAN que permite a los operadores
emplear ATM o IP para la transmisión y actualmente se introduce IMS (IP Multimedia
Subsystem). Las opciones de arquitectura mencionadas proporcionan la posibilidad de
desplegar dominios de red sobre un backbone IP único, por lo tanto es aplicable el
modelo NGN en las redes de telefonía móvil.

DEFINICIÓN DE NGN

Hasta el momento el concepto de NGN no existe una única definición que sea válida.
Según los distintos actores involucrados en las telecomunicaciones es muy difícil llegar
a una definición que abarque todos los escenarios posibles de la Red de Nueva
Generación.

Como sabemos el mundo de las telecomunicaciones ha existido una separación entre la


voz y los datos, lo que a motivado a los organismos de control y estandarización dar
diferentes reglas, es decir mientras las normas de voz son de carácter obligatorio, para
los datos se desarrollan recomendaciones, por consenso entre fabricantes y operadores.
Esta situación ha provocado la existencia de 2 puntos de vista, hacia el concepto NGN:

1. Los datos de Internet.


 La red dará soporte de conectividad a un conjunto de elementos
terminales inteligentes. El control y establecimiento de las sesiones será
responsabilidad de los terminales.
 Los servicios son totalmente independientes de la red.
 Los servicios tradicionales desaparecerán en forma paulatina, dando a
nuevos servicios muchos de ellos desconocidos aun.

2. Con respecto a la voz.


 Los servicios se darán a través de redes interconectadas sobre un
conjunto de terminales inteligentes y no inteligentes.
 La red tradicional evolucionará para adaptarse a servicios multimedia
costituyendo la base de NGN.
 La provisión de servicios se desarrollaran sobre interfaces abiertas.
En las Redes de Nueva Generación se identificarán dos tipos de clientes: el grupo
empresarial, en el cual el atractivo será los servicios tradicionales (voz, redes virtuales).
En el sector residencial el atractivo será mejorar los actuales servicios, reducir los costes
y ampliar los servicios de entretenimiento.

Los fabricantes y organismos de regulación han dado su definición del concepto de


NGN, de las cuales hemos extraído las siguientes:

 Para Telcordia, NGN es una red de transporte y conmutación a alta velocidad


para servicios de voz, faz, datos y video, realizados de forma integrada.
 Para ETSI y “NGN Starter Group”, NGN es un concepto para la definición y
despliegue de redes con interfaces abiertos, que ofrece a los proveedores de
servicios una plataforma sobre la que sea posible evolucionar paso a paso para
crear, desplegar y gestionar servicios innovadores.
 Para la ITU (Internacional Telecommunication Union), NGN es una red de
paquetes capaz de proveer servicios de telecomunicaciones y capaz de hacer uso
de múltiples tecnologías de banda ancha y ofrecer diferentes niveles de QoS, y
en el cual las funciones relacionadas con el servicio son independientes de las
tecnologías de transporte. Esto habilita el acceso a los usuarios a redes y
proveedores y servicios de su gusto. Soporta movilidad generalizada, la cual
permitirá provisión de servicios ubicuos a los usuarios.
 Para Vint Cerf, participante en el proyecto ARPNET (Adanced Research
Projecst Agency Network), NGN es como cualquier otra idea sobre arquitectura
de redes, un proceso evolutivo, que tal vez estará salpicado de alguna sorpresa.
 Algunos fabricantes de equipos definen a NGN como una red única y abierta, de
paquetes, basada en estándares, capaz de soportar un gran número de
aplicaciones y servicios, con escalabilidad necesaria para afrontar las futuras
demandas del trafico IP y con flexibilidad adecuada para responder rápidamente
a las exigencias del mercado.

Entonces una definición clara según varios criterios es que NGN es una red que
permitirá la integración de servicios multimedia (voz, video y datos), en un único
modelo de infraestructura de red.

CARACTERISTICAS FUNDAMENTASLES DE NGN.

Según la definición de NGN hay que tener en consideración las siguientes


características de una red:

 La convergencia de los servicios de voz, video y datos se hará sobre la


misma infraestructura de red.
 Dispondrá de interfaces abiertas y protocolos estándares.
 La conmutación de paquetes utilizará protocolos IPv4/IPv6, con soporte
MPLS (Multiprotocol Label Switch).
 La calidad de servicio (QoS), para el caso de los servicios de voz deberá
tener niveles de calidad de la red tradicional.
 La red deberá ser capaz de manejar una variedad de tráfico desde
transferencia de archivos sencillos hasta servicios de multimedia.
 Soportar acceso alámbrico e inalámbrico con más ancho de banda del que se
dispone actualmente.
 Dispondrá de escalabilidad, fiabilidad, disponibilidad y seguridad.

Además deberá de disponer de ciertos elementos indispensables para que pueda ser
considerada como una Red de Nueva Generacion:

 Los sistemas de transmisión serán de última generación, basados en tecnologías


ópticas WDM (Wavelength Division Multiplexing).
 Los elementos de conmutación serán del tipo GSR (Gigabit Switch Router) o
TSR (Terabit Switch Router), conformando una red IPv4/IPv6 con soporte
MPLS.
 Disponer de políticas de seguridad en la red y a nivel de los usuarios.
 Disponer de políticas de calidad de servicios que sean operativas.
 Desarrollar una estructura de red escalable que permita la evolución de la red
acorde a los avances tecnológicos.
 Disponer de un sistema de respaldo de información de todos los equipos
involucrados en el funcionamiento de la red.
 Garantizar el permanente funcionamiento de los equipos, además de llevar una
bitácora de todas las actividades realizadas.

PROTOCOLOS UTILIZADOS PARA LAS REDES


DENUEVA GENERACIÓN

A continuación se presenta un resumen detallado de cada uno de los protocolos que se


utilizan para redes de nueva generación. Para un entendimiento más claro del
funcionamiento de todos los protocolos de redes NGN, al final de este proyecto se
encuentra un CD en el que se presenta los RFCs correspondientes a cada uno de los
protocolos.

PROTOCOLOS H.323
H.323 es una recomendación del ITU-T (International Telecommunication Union), que
define los protocolos para proveer sesiones de comunicación audiovisual sobre paquetes
de red. A partir del año 2000 se encuentra implementada por varias aplicaciones de
internet que funcionan en tiempo real como Microsoft Netmeeting y GnomeMeeting. Es
una parte de la serie de protocolos H.32x, los cuales también dirigen las comunicaciones
sobre RDSI, RTC o SS7. H.323 es utilizado comúnmente para Voz sobre IP (VoIP,
Telefonía de internet o Telefonía IP) y para videoconferencia basada en IP. Es un
conjunto de normas (recomendación paragüas) ITU para comunicaciones multimedia
que hacen referencia a los terminales, equipos y servicios estableciendo una
señalización en redes IP. No garantiza una calidad de servicio, y en el transporte de
datos puede, o no, ser fiable; en el caso de voz o vídeo, nunca es fiable. Además, es
independiente de la topología de la red y admite pasarelas, permitiendo usar más de un
canal de cada tipo (voz, vídeo, datos) al mismo tiempo.
A continuación se mencionan ver diferentes elementos que conforman la topología
clásica de una red basada en H-323.
 Portero: realiza el control de llamada en una zona. Es opcional pero su uso está
recomendado, de modo que si existe, su uso será obligatorio. Traduce
direcciones, ofrece servicio de directorio, control de admisión de terminales,
control de consumo de recursos y procesa la autorización de llamdas, así como
también puede encaminar la señalización.
 Pasarela: es el acceso a otras redes, de modo que realiza funciones de
transcodificación y traducción de señalización.
 MCU: soporte multiconferencia. Se encarga de la negociación de capacidades.

HISTORIA
H.323 se creó originalmente para proveer de un mecanismo para el transporte de
aplicaciones multimedia en LANs (Redes de área local) pero ha evolucionado
rápidamente para dirigir las crecientes necesidades de las redes de VoIP.
Un punto fuerte de H.323 era la relativa y temprana disponibilidad de un grupo de
estándares, no solo definiendo el modelo básico de llamada, sino que además definía
servicios suplementarios, necesarios para dirigir las expectativas de comunicaciones
comerciales. H.323 fue el primer estándar de VoIP en adoptar el estándar de IETF de
RTP (Protocolo de Transporte en tiempo Real) para transportar audio y vídeo sobre
redes IP.
H.323 está basado en el protocolo RDSI Q.931 y está adaptado para situaciones en las
que se combina el trabajo entre IP y RDSI, y respectivamente entre IP y QSIG. Un
modelo de llamada, similar al modelo de RDSI, facilita la introducción de la Telefonía
IP en las redes existentes de RDSI basadas en sistemas PBX. Por esto es posible el
proyecto de una migración sin problemas hacia el IP basado en sistemas PBX.
Dentro del contexto de H.323, un IP basado en PBX es, en palabras sencllas, un
Gatekeeper más algunos servicios suplementarios.
PILA DE PROTOCOLOS H.323:
El VoIP/H.323 comprende una serie de protocolos que cubren los distintos aspectos de
la comunicación:
DIRECCIONAMIENTO:
 RAS (Registration, Admision and Status): Protocolo de comunicaciones que
permite a una estación H.323 localizar otra estación H.323 a través del
Gatekeeper.
 DNS (Domain Name Service): Servicio de resolución de nombres en direcciones
IP con el mismo fin que el protocolo RAS pero a través de un servidor DNS.
SEÑALIZACIÓN:
 H.225 (RAS): Protocolo que permite a los terminales hablar con el Gatekeeper,
solicitar y regresar ancho de banda y proporcionar actualizaciones de estado.
 Q.931: Protocolo de señalización de llamadas, para establecer y liberar las
conexiones con la red telefónica RTC.
 H.245: Protocolo de control de llamadas, permite a los terminales negociar
ciertos parámetros como: el tipo de Codec, la tasa de bits.
COMPRESIÓN DE VOZ:
 Requeridos: G.711 y G.723.1
 Opcionales: G.728, G.729 y G.722
TRANSMISIÓN DE VOZ:
 UDP: La transmisión se realiza sobre paquetes UDP, pues aunque UDP no
ofrece integridad en los datos, el aprovechamiento del ancho de banda es mayor
que con TCP.
 RTP (Real Time Protocol): Maneja los aspectos relativos a la temporización,
marcando los paquetes UDP con la información necesaria para la correcta
entrega de los mismos en recepción.
CONTROL DE LA TRANSMISIÓN:
 RTCP (Real Time Control Protocol): Es un protocolo de control de los canales
RTP. Se utiliza principalmente para detectar situaciones de congestión de la red
y tomar, en su caso, acciones correctoras.
La arquitectura de protocolos se muestra en la siguiente figura siguiente.
COMPONENTES DE UNA RED VoIP:
Las redes de VoIP suelen contener los siguientes componentes fundamentales, según se
muestra en la figura teléfonos IP’s, adaptadores para PC’s, Hubs telefónicos, Gateways
H.323, Gatekeeper, Unidades de Conferencia Multimedia (MCU).

1. EL GATEKEEPER: todos los elementos de red de VoIP (terminales, Gateways,


MCU) tienen que usar el Gatekeeper como punto intermedio para la
señalización. Los elementos de red se comunican con el Gatekeeper de VoIP
utilizando el protocolo RAS H.225. Los Gatekeepers actúan como controladores
del sistema y cumplen con el segundo nivel de funciones esenciales en el
sistema de VoIP de clase carrier, es decir, autenticación, enrutamiento del
servidor de directorios, contabilidad de llamadas y determinación de tarifas. Los
Gatekeepers utilizan la interfaz estándar de la industria ODBC-32 (Open Data
Base Connectivity – Conectividad abierta de bases de datos), para acceder a los
servidores de backend en el centro de cómputo del Carrier y así autenticar a las
personas que llaman como abonados válidos al servicio, optimizar la selección
del gateway de destino y sus alternativas, hacer un seguimiento y una
actualización de los registros de llamadas y la información de facturación, y
guardar detalles del plan de facturación de la persona que efectúa la llamada.

2. EL GATEWAY: provee un acceso permanente a la red IP. Las llamadas de voz


se digitalizan, codifican, comprimen y paquetizan en un Gateway de origen y
luego, se descomprimen, decodifican y rearman en el gateway de destino. El
Gateway es un elemento esencial en la mayoría de las redes pues su misión es la
de enlazar la red VoIP con la red telefónica analógica PSTN o RDSI. Podemos
considerar al Gateway como una caja que por un lado tiene un Interface LAN
Ethernet, Frame Relay o ATM y por el otro dispone de uno o varios de los
siguientes interfaces:
o FXO. Para conexión a extensiones de centralitas ó a la red telefónica
básica.
o FXS. Para conexión a enlaces de centralitas o a teléfonos analógicos.
o E&M. Para conexión específica a centralitas.
o BRI. Acceso básico RDSI (2B+D)
o PRI. Acceso primario RDSI (30B+D)
o G703/G.704. (E&M digital) Conexión especifica a centralitas a 2 Mbps.
3. Tiene las siguientes funciones básicas:
o Autenticación y control de admisión, para permitir o denegar el acceso
de usuarios.
o Proporciona servicios de control de llamada.
o Servicio de traducción de direcciones (DNS), de tal manera que se
puedan usar nombres en lugar de direcciones IP.
o Gestionar y controlar los recursos de la red: Administración del ancho de
banda.
o Localizar los distintos Gateways y MCU’s cuando se necesita.
4. El procesamiento que realiza el gateway de la cadena de audio que atraviesa una
red IP es transparente para los usuarios. Desde el punto de vista de la persona
que llama, la experiencia es muy parecida a utilizar una tarjeta de llamada
telefónica. La persona que realiza la llamada ingresa a un gateway por medio de
un teléfono convencional discando un número de acceso. Una vez que fue
autenticada, la persona disca el número deseado y oye los tonos de llamada
habituales hasta que alguien responde del otro lado. Tanto quien llama como
quien responde se sienten como en una llamada telefónica "típica". Tenemos dos
tipos de Gateways:
o Gateway H.323/H.320: básicamente realiza la conversión entre estos dos
formatos de forma que los terminales H.323 se pueden comunicar con
equipos RDSI de videoconferencia, que pueden formar parte de la red
corporativa o estar situados en la red pública.
o Gateway H.323/RTB (Voz sobre IP). Posibilitan las comunicaciones de
voz entre los terminales H.323 y los teléfonos convencionales, estén en
la red corporativa o en la red pública.
1. TERMINAL H.323: son los clientes que inician una conexión VoIP.
Pueden ser de dos tipos:
2. IP PHONE: o teléfonos IP, se muestra en la figura.

3. SOFT PHONE; se trata normalmente de una PC multimedia que simula un


teléfono IP, por ejemplo, el servicio de NetMeeting utiliza protocolo H.323.
a. MCU’s H.323: se utiliza cuando han de intervenir más de dos partes en
una conferencia. La MCU (Multimedia Conference Unit) es responsable
de controlar las sesiones y de efectuar el mezclado de los flujos de audio,
datos y video.
b. ADAPTADOR PARA PC: más conocido como ATA, es un adaptador de
teléfono analógico que se conecta al servicio de cable MODEM o al
servicio de DSL, que permite obtener telefonía por Internet.
Protocolos que forman parte de H.323
H.323 tiene referencias hacia algunos otros protocolos de ITU-T como:
 H.225.0 - Protocolo utilizado para describir la señal de llamada, el medio (audio
y video), el empaquetamiento de las tramas, la sincronización de tramas de
medio y los formatos de los mensajes de control.
 H.245 - Protocolo de control para comunicaciones multimedia. Describe los
mensajes y procedimientos utilizados para abrir y cerrar canales lógicos para
audio, video y datos, capacidad de intercambio, control e indicaciones.
 H.450 - Describe los Servicios Suplementarios.
 H.235 - Describe la seguridad de H.323.
 H.239 - Describe el uso de la doble trama en videoconferencia, normalmente
uno para video en tiempo real y la otro para presentación.
 H.281 - Describe el control de cámara lejana para movimientos PTZ (Pan-Tilt-
Zoom)
PROTOCOLO H.225.0
H.225.0 es un protocolo de comunicaciones de la familia de protocolos H.323,
utilizados comúnmente para Voz sobre IP y para videoconferencia basada en IP. El
principal objetivo de H.225.0 es la definición de mensajes:
 Señalización de llamada: establecimiento, control y finalización de una llamada
H.323. La señalización H.225.0 está basada en los procedimientos de
establecimiento de llamada de RDSI, Recomendación Q.931.
 Señalización RAS: lleva a cabo los procedimientos de registro, admisión,
cambios de ancho de banda, estado y desconexión entre puntos finales y un
Gatekeeper H.323. La función de señalización RAS usa un canal separado (canal
RAS). Este conjunto de mensajes recibe el nombre de Registro, Admisión y
Estado (del inglés Registration, Admission and Status - RAS).
Los mensajes son codificados de acuerdo a las Normas de Codificación de Paquetes (del
inglés Packed Encoding Rules - PER) de la norma ASN.1.La estructura de H.225 sigue
el estándar Q.931 tal y como se ve en la siguiente tabla:
PROTOCOLO H.245
H.245 es un protocolo de control de canal usado dentro de sesiones de comunicación
H.323. También ofrece la posibilidad de ser tunelizado dentro de los mensajes de
señalización de llamada de H.225.0. Esto facilita su paso a través de los cortafuegos.
H.245 tiene la capacidad de transmitir y proporcionar la información necesaria para la
comunicación multimedia, tal como la codificación, el control de flujo, la gestión de
jitter y las peticiones de preferencia, así como el procedimiento de apertura y cierre de
los canales lógicos usados para transmitir los flujos de medios. También define
capacidades de envío y recibo separadas y los métodos para enviar estos detalles a otros
dispositivos que soporten H.323.
Un problema grave que tenía la versión inicial de H.323 era el prolongado mecanismo
de establecimiento de comunicación del protocolo H.245, necesario durante la apertura
de los canales lógicos de una sesión telefónica, que era de cuatro vías. Versiones
posteriores de H.323 introdujeron el procedimiento de Conexión Rápida, usando el
elemento fastStart de un mensaje H.225.0. La Conexión Rápida redujo la negociación a
tan solo dos vías. Existe otra recomendación, la H.460.6, que define el Procedimiento
Extendido de Conexión Rápida, el cual fija un mecanismo de establecimiento de
comunicación de una sola vía.
PROTOCOLO H.235
H.235 se encarga de la seguridad y el cifrado para terminales basados en H.323 y
H.245.
El estándar aborda la Autenticación mediante diferentes algoritmos, incluidos los
métodos Diffie-Hellman, y la Privacidad. La Privacidad proporciona el cifrado de la
sesión, así como de los flujos de datos. El comité de estandarización acordó en H.235
que lo detallado en el Anexo D serán los requisitos mínimos para una implementación
que cumpla el estándar. El Anexo D, también conocido como el "Perfil de Seguridad
Básico" define la Autenticación y la Integridad.
Un Gatekeeper que cumpla el Anexo D podrá de tal modo asegurar que solamente los
puntos finales H.323 confiables tendrán acceso a los servicios del Gatekeeper.
PROTOCOLO SIP
Session Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo
desarrollado por el IETF MMUSIC Working Group con la intención de ser el estándar
para la iniciación, modificación y finalización de sesiones interactivas de usuario donde
intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos
online y realidad virtual. En Noviembre del año 2000, SIP fue aceptado como el
protocolo de señalización de 3GPP y elemento permanente de la arquitectura IMS (IP
Multimedia Subsystem). SIP es uno de los protocolos de señalización para voz sobre IP,
acompañado por H.323.

Diseño del protocolo


Los clientes SIP usan el puerto 5060 en TCP (Transmission Control Protocol) y UDP
(User Datagram Protocol) para conectar con los servidores SIP. SIP es usado
simplemente para iniciar y terminar llamadas de voz y video. Todas las comunicaciones
de voz/video van sobre RTP (Real-time Transport Protocol). Un objetivo de SIP fue
aportar un conjunto de las funciones de procesamiento de llamadas y capacidades
presentes en la red pública conmutada de telefonía. Así, implementó funciones típicas
que permite un teléfono común como son: llamar a un número, provocar que un
teléfono suene al ser llamado, escuchar la señal de tono o de ocupado. La
implementación y terminología en SIP son diferentes. SIP también implementa muchas
de las más avanzadas características del procesamiento de llamadas de SS7, aunque los
dos protocolos son muy diferentes. SS7 es altamente centralizado, caracterizado por una
compleja arquitectura central de red y unos terminales tontos (los tradicionales teléfonos
de auricular). SIP es un protocolo punto a punto (también llamado p2p). Como tal
requiere un núcleo de red sencillo (y altamente escalable) con inteligencia distribuida en
los extremos de la red, incluida en los terminales (ya sea mediante hardware o
software). Muchas características de SIP son implementadas en los terminales en
oposición a las tradicionales características de SS7, que son implementadas en la red.
Aunque existen muchos otros protocolos de señalización para VoIP, SIP se caracteriza
porque sus promotores tienen sus raíces en la comunidad IP y no en la industria de las
telecomunicaciones. SIP ha sido estandarizado y dirigido principalmente por el IETF
mientras que el protocolo de VoIP H.323 ha sido tradicionalmente más asociado con la
Unión Internacional de Telecomunicaciones. Sin embargo, las dos organizaciones han
promocionado ambos protocolos del mismo modo.
SIP funciona en colaboración con otros muchos protocolos pero solo interviene en la
parte de señalización al establecer la sesión de comunicación. SIP actúa como envoltura
al SDP, que describe el contenido multimedia de la sesión, por ejemplo qué puerto IP y
códec se usarán durante la comunicación, etc. En un uso normal, las sesiones SIP son
simplemente flujos de paquetes de RTP (Real-time Transport Protocol). RTP es el
verdadero portador para el contenido de voz y video.
La primera versión propuesta para estándar (SIP 2.0) fue definida en el RFC 2543. El
protocolo aclarado en el RFC 3261, aunque muchas implementaciones están usando
todavía versiones en fase de borrador. Hay que fijarse en que el número de versión sigue
siendo 2.0.
SIP es similar a HTTP y comparte con él algunos de sus principios de diseño: es legible
por humanos y sigue una estructura de petición-respuesta. Los promotores de SIP
afirman que es más simple que H.323. Sin embargo, aunque originalmente SIP tenía
como objetivo la simplicidad, en su estado actual se ha vuelto tan complejo como
H.323. SIP comparte muchos códigos de estado de HTTP, como el familiar '404 no
encontrado' (404 not found). SIP y H.323 no se limitan a comunicaciones de voz y
pueden mediar en cualquier tipo de sesión comunicativa desde voz hasta vídeo o futuras
aplicaciones todavía sin realizar.
Elementos SIP de red
Los terminales físicos, dispositivos con el aspecto y forma de teléfonos tradicionales,
pero que usan SIP y RTP para la comunicación, están disponibles comercialmente
gracias a muchos fabricantes. Algunos de ellos usan numeración electrónica (ENUM) o
DUNDi para traducir los números existentes de teléfono a direcciones SIP usando DNS
(Domain Name Server), así llaman a otros usuarios SIP saltándose la red telefónica, con
lo que tu proveedor de servicio normalmente actúa de pasarela hacia la red pública
conmutada de telefonía para los números de teléfono tradicionales (cobrándote por ello).
Hoy en día, ya son habituales los terminales con soporte SIP por software.
Mensajería instantánea y presencia
Un protocolo de mensajería instantánea basado en SIP, llamado SIMPLE, fue propuesto
como estándar y está en desarrollo. SIMPLE puede también encargarse de la
información de presencia, transmitiendo la voluntad de una persona de entablar
comunicación con otras. La información de presencia es más reconocible hoy en día
como el estado en los clientes de mensajería instantánea como MSN Messenger, AIM y
Skype.
Se han realizado algunos esfuerzos para integrar la voz sobre IP (VoIP) con la
especificación XMPP usada por Jabber. El más notable ha sido Google Talk, que
extiende XMPP para soportar voz, diseñado para integrar SIP. La extensión XMPP de
Google se llama "Jingle" 1 2 y como SIP actúa de portador para SDP.
Otros RFC que el documento del SIP son:
 RFC 3262 - Fiabilidad de las respuestas provisionales en el Protocolo de
Iniciación de Sesión (SIP)
 RFC 3263 - Protocolo de Iniciación de Sesión (SIP): Localización de los
servidores SIP
 RFC 3264 - Una Oferta / Responder con el Modelo de Protocolo de Descripción
de Sesión (SDP)
 RFC 3265 - Protocolo de Iniciación de Sesión (SIP)-específicos de notificación
de eventos

PROTOCOLO IP
El protocolo IP es el software que implementa el mecanismo de entrega de paquetes sin
conexión y no confiable (técnica del mejor esfuerzo). El protocolo IP cubre tres
aspectos importantes:
1. Define la unidad básica para la transferencia de datos en una interred,
especificando el formato exacto de un Datagrama IP.
2. Realiza las funciones de enrutamiento.
3. Define las reglas para que los Host y Routers procesen paquetes, los descarten o
generen mensajes de error.
El Datagrama IP
El esquema de envío de IP es similar al que se emplea en la capa Acceso a red. En esta
última se envían Tramas formadas por un Encabezado y los Datos. En el Encabezado se
incluye la dirección física del origen y del destino. En el caso de IP se envían
Datagramas, estos también incluyen un Encabezado y Datos, pero las direcciones
empleadas son Direcciones IP.
Encabezado Datos
Formato del Datagrama IP
Los Datagramas IP están formados por Palabras de 32 bits. Cada Datagrama tiene un
mínimo (y tamaño más frecuente) de cinco palabras y un máximo de quince.

 Ver: Versión de IP que se emplea para construir el Datagrama. Se requiere para


que quien lo reciba lo interprete correctamente. La actual versión IP es la 4.
 Hlen: Tamaño de la cabecera en palabras.
 TOS: Tipo de servicio. La gran mayoría de los Host y Routers ignoran este
campo. Su estructura es:
Prioridad D T R Sin Uso
La prioridad (0 = Normal, 7 = Control de red) permite implementar algoritmos de
control de congestión más eficientes. Los tipos D, T y R solicitan un tipo de transporte
dado: D = Procesamiento con retardos cortos, T = Alto Desempeño y R = Alta
confiabilidad. Nótese que estos bits son solo "sugerencias", no es obligatorio para la red
cumplirlo.
 Longitud Total: Mide en bytes la longitud de doto el Datagrama. Permite
calcular el tamaño del campo de datos: Datos = Longitud Total
– 4 * Hlen.
Antes de continuar con la segunda palabra del Datagrama IP, hace falta introducir
conceptos relacionados con la fragmentación.
Fragmentación
En primer lugar, De qué tamaño es un Datagrama?. El tamaño para un Datagrama debe
ser tal que permita la encapsulación, esto es, enviar un Datagrama completo en una
trama física. El problema está en que el Datagrama debe transitar por diferentes redes
físicas, con diferentes tecnologías y diferentes capacidades de transferencia. A la
capacidad máxima de transferencia de datos de una red física se le llama MTU (el MTU
de ethernet es 1500 bytes por trama, la de FDDI es 4497 bytes por trama).
Cuando un Datagrama pasa de una red a otra con un MTU menor a su tamaño es
necesaria la fragmentación. A las diferentes partes de un Datagrama se les llama
fragmento. Al proceso de reconstrucción del Datagrama a partir de sus fragmentos se le
llama Reensamblado de fragmentos. El control de la fragmentación de un Datagrama IP
se realiza con los campos de la segunda palabra de su cabecera:
 Identificación: Numero de 16 bits que identifica al Datagrama, que permite
implementar números de secuencias y que permite reconocer los diferentes
fragmentos de un mismo Datagrama, pues todos ellos comparten este numero.
 Banderas: Un campo de tres bits donde el primero está reservado. El segundo,
llamado bit de No - Fragmentación significa: 0 = Puede fragmentarse el
Datagrama o 1 = No puede fragmentarse el Datagrama. El tercer bit es llamado
Más – Fragmentos y significa: 0 = Unico fragmento o Ultimo fragmento, 1 =
aun hay más fragmentos. Cuando hay un 0 en más – fragmentos, debe evaluarse
el campo desp. De Fragmento: si este es cero, el Datagrama no esta
fragmentado, si es diferente de cero, el Datagrama es un ultimo fragmento.
 Desp. De Fragmento: A un trozo de datos se le llama Bloque de Fragmento. Este
campo indica el tamaño del desplazamiento en bloques de fragmento con
respecto al Datagrama original, empezando por el cero.
Para finalizar con el tema de fragmentación, hay que mencionar el Plazo de
Reensamblado, que es un time out que el Host destino establece como máximo para
esperar por todos los fragmentos de un Datagrama. Si se vence y aun no llegan
TODOS, entonces se descartan los que ya han llegado y se solicita el reenvío del
Datagrama completo.
Formato del Datagrama IP
 TTL: Tiempo de Vida del Datagrama, especifica el numero de segundos que se
permite al Datagrama circular por la red antes de ser descartado.
 Protocolo: Especifica que protocolo de alto nivel se empleó para construir el
mensaje transportado en el campo datos de Datagrama IP.
Algunos valores posibles son: 1 = ICMP, 6 = TCP, 17 = UDP, 88 = IGRP
(Protocolo de Enrutamiento de Pasarela Interior de CISCO).
 Checksum: Es un campo de 16 bits que se calcula haciendo el complemento a
uno de cada palabra de 16 bits del encabezado, sumándolas y haciendo su
complemento a uno. Esta suma hay que recalcularla en cada nodo intermedio
debido a cambios en el TTL o por fragmentación.
 Dirección IP de la Fuente:
 Dirección IP del Destino:
 Opciones IP: Existen hasta 40 bytes extra en la cabecera del Datagrama IP que
pueden llevar una o más opciones. Su uso es bastante raro.
o Uso de Ruta Estricta (Camino Obligatorio).
o Ruta de Origen Desconectada (Nodos Obligatorios).
o Crear registro de Ruta.
o Marcas de Tiempo.
o Seguridad Básica del Departamento de Defensa.
o Seguridad Extendida del Departamento de Defensa.
Enrutamiento IP
Enrutar es el proceso de selección de un camino para el envío de paquetes. La
computadora que hace esto es llamada Router.
En general se puede dividir el enrutamiento en Entrega Directa y Entrega Indirecta. La
Entrega Directa es la transmisión de un Datagrama de una maquina a otra dentro de la
misma red física. La Entrega Indirecta ocurre cuando el destino no esta en la red local,
lo que obliga al Host a enviar el Datagrama a algún Router intermedio. Es necesario el
uso de mascaras de subred para saber si el Host destino de un Datagrama esta o no
dentro de la misma red física.
Encaminamiento con Salto al Siguiente.
La forma más común de enrutamiento requiere el uso de una Tabla de Enrutamiento IP,
presente tanto en los Host como en los Routers. Estas tablas no pueden tener
información sobre cada posible destino, de hecho, esto no es deseable. En ves de ello se
aprovecha el esquema de direcionamiento IP para ocultar detalles acerca de los Host
individuales, además, las tablas no contienen rutas completas, sino solos la dirección del
siguiente paso en esa ruta.
En general una tabla de encaminamiento IP tiene pares (Destino, Router), donde destino
es la dirección IP de un destino particular y Router la dirección del siguiente Router en
el camino hacia destino. Nótese que Router debe ser accesible directamente desde la
maquina actual.
Este tipo de encaminamiento trae varias consecuencias, consecuencia directa de su
naturaleza estática:
1. Todo trafico hacia una red particular toma el mismo camino,
desaprovechando caminos alternativos y el tipo de trafico.
2. Solo el Router con conexión directa al destino sabe si este existe o
estaactivo.
3. Es necesario que los Routers cooperen para hacer posible la comunicación
bidireccional.
Manejo de Datagramas Entrantes.
Cuando un Datagrama llega a un Host, el software de red lo entrega a IP. IP verifica la
dirección de destino y si esta concuerda con la de la maquina local, entonces acepta el
Datagrama y lo entrega a las capas superiores. De no coincidir la dirección de destino,
el Datagrama es descartado.
Por otra parte, un Router que reciba un Datagrama compara la dirección de destino con
la suya propia. Si coinciden, el Datagrama pasa a las capas superiores, sino, se le aplica
el algoritmo de encaminamiento y se reenvía el Datagrama.
Direccionamiento sin Clase
Durante la introducción a TCP/IP (Juan Carlos Guevara), se explicaba como mediante
el empleo de Mascaras de subred, se lograba convertir una única red (generalmente una
Clase B) en múltiples redes lógicas interconectadas y administradas por la organización
propietaria. El problema se presenta cuando el crecimiento explosivo de las redes
locales produce el fenómeno ROADS (Running Out of Address Space), que consiste
simplemente en el agotamiento del espacio de direcciones útil, causado por la gran
demanda de las direcciones Clase B, de las cuales solo hay 16.384, mientras que las
Clases C permanecían sin Asignar (pues aunque hay 2.097.152 de ellas, nadie las quiere
por ser muy pequeñas).
Para enfrentar este problema se desarrollo el esquema de Direcciones sin Clase, que
consiste en asignar a una misma organización un bloque continuo de direcciones de
Clase C. De esta manera, una organización que requiera conectar a Internet un numero
moderado de Hosts (digamos 3.800) puede recibir un bloque de 16 redes continuas de
Clase C (por ejemplo, de la red Clase C 199.40.72.0 a la 199.40.87.0), con lo cual
dispone de 4.096 direcciones IP validas para administrar.
CIDR Enrutamiento Inter – Dominio Sin Clases (Classless Inter – Domain Routing)
El esquema de direcciones sin clase genera el problema de aumentar la información que
debe incluirse en las tablas de enrutamiento. En el caso del ejemplo, se tendría que
incluir 16 nuevas entradas en cada tabla de enrutamiento de cada Host y Router. CIDR
resuelve el problema al incluir en las tablas información acerca del tamaño de los
bloques y el numero de bloques, así, en las tablas de enrutamiento IP se tienen pares
(Destino, Router), donde destino no es una dirección de Host o Red tradicional, sino que
incluye información acerca del numero de redes que incluye el bloque (en nuestro
ejemplo, 16) y el tamaño de cada una de esas redes (en el ejemplo, son Clases C, 256
direcciones cada una).
El Direccionamiento sin clase modifica la estructura de una dirección IP, de esta
manera:
Prefijo de Red Identificador de Host
Así, CIDR debe incluir en las tablas de enrutamiento cual es la primera red que
compone el bloque, cuantos bits se emplean como Prefijo de Red y la mascara de subred
que se emplea. En nuestro ejemplo, las tablas de enrutamiento IP contendrían esta
información:
199.40.72.0/20 255.255.240.0 Refiriéndose a un bloque que se inicia con la red
199.40.72.0 y que tiene 20 bits en el prefijo de red. La mascara 255.255.240.0
(11111111.11111111.11110000.00000000) nos indica que se están usando 4 bits extra
(los que se han resaltado) para identificar a las redes que componen al bloque. Nótese
que cuatro bits permites agrupar precisamente 16 redes Clase C.
Un aspecto importante que hay que subrayar es que en ningún momento cambia el
algoritmo básico de enrutamiento IP, lo que cambia es el contenido de las tablas.
Además, las nuevas tablas contienen información resumida, por lo que buscar una
dirección destino en la tabla se hace de otra manera, pero el algoritmo permanece
inalterado.
El problema de buscar direcciones de destino en una tabla, consiste en que cualquier
dirección cuya mascara de destino tenga menos bits, incluye a la que tiene mas bits. Con
esto quiero decir que una mascara de subred como 255.255.0.0
(11111111.11111111.00000000.00000000, es decir, 16 bits de prefijo de red) incluye
dentro de si a la mascaras de subred 255.255.128.0
(11111111.11111111.10000000.00000000, 17 bits de prefijo de red) y esta a su ves
incluye a la mascara 255.255.192.0 (11111111.11111111.11000000.00000000) y en
general, entre menos bits tiene el prefijo de red, mas direcciones Host abarca. Por esta
razón cuando se explora la tabla de enrutamiento IP en busca de una dirección de
destino, se hace una búsqueda que inicia con las mascaras de más bits y termina en la de
menos bits. Es decir, se inicia con mascaras como 255.255.255.255 (todo en uno) y se
continua con la 255.255.255.254 (31 unos y un cero) y así sucesivamente. Esto quiere
decir que tendrían que hacerse 32 recorridos secuenciales a la tabla, lo cual es muy
ineficiente en cuanto a tiempo, pues además de ser un procedimiento demorado, se sabe
ya que direcciones normales de Clase B (255.255.0.0) requieren 16 barridos a la tabla,
además, hacen falta 32 barridos para notar que no hay una entrada en la tabla para esas
dirección. Por esta razón se emplean otros métodos para hacer estas búsquedas en las
tablas de enrutamiento IP. Un esquema muy popular emplea un Arbol Binario, en el
cual cada bit representa una nueva rama en el árbol.
Así, en nuestro ejemplo, podrían dividirse las direcciones asignadas a la organización
(4.096) en subredes de esta forma: dos subredes de 1.024 direcciones cada una, tres de
512 y dos de 256 direcciones. De esta forma, el árbol resultante tendría esta forma:
PROTOCOLO IPv4
IPv4 es la versión 4 del Protocolo IP (Internet Protocol). Esta fue la primera versión del
protocolo que se implementó extensamente, y forma la base de Internet.
IPv4 usa direcciones de 32 bits, limitándola a 232 = 4.294.967.296 direcciones únicas,
muchas de las cuales están dedicadas a redes locales (LANs). Por el crecimiento enorme
que ha tenido del Internet (mucho más de lo que esperaba, cuando se diseñó IPv4),
combinado con el hecho de que hay desperdicio de direcciones en muchos casos (ver
abajo), ya hace varios años se vio que escaseaban las direcciones IPv4. Esta limitación
ayudó a estimular el impulso hacia IPv6, que esta actualmente en las primeras fases de
implementación, y se espera que termine reemplazando a IPv4.
Desperdicio de direcciones
El desperdicio de direcciones IPv4 se debe a varios factores. Uno de los principales es
que inicialmente no se consideró el enorme crecimiento que iba a tener Internet; se
asignaron bloques de direcciones grandes (de 16,7 millones de direcciones) a países, e
incluso a empresas.
Otro motivo de desperdicio es que en la mayoría de las redes, exceptuando las más
pequeñas, resulta conveniente dividir la red en subredes. Dentro de cada subred, la
primera y la última dirección no son utilizables; de todos modos no siempre se utilizan
todas las direcciones restantes. Por ejemplo, si en una subred se quieren acomodar 80
hosts, se necesita una subred de 128 direcciones (se tiene que redondear a la siguiente
potencia de 2); en este ejemplo, las 48 direcciones restantes ya no se utilizan.
Este protocolo está bien asentado comercialmente, pero se le atribuyen tres deficiencias:
1. No soporta la calidad de servicio.
2. No es seguro.
3. Tiene un campo de direccionamiento limitado.
En cuanto al primer aspecto se puede decir que IPv4 en realidad sí que soporta la
calidad de servicio, aunque el verdadero problema es que hasta ahora no se ha
implementado en los equipos de red de forma general.
Además, los aspectos de calidad de servicio y seguridad no son realmente problema del
protocolo de red, sino del modelo de red, tal como lo demuestran los estándares
DiffServ e IPSec. Por tanto, los requisitos de calidad de servicio y seguridad no son
responsabilidad del protocolo y están soportados por los estándares ya mencionados,
apoyándose para su funcionamiento en los recursos que ofrece para ello el protocolo
IPv4.
En el caso particular de la calidad de servicio, existe un requisito que involucra al
protocolo y es la codificación del concepto de jerarquización de tráfico, que en el caso
de IPv4 estará soportado por el campo ToS de 8 bits. Cuando este campo se utiliza
directamente está estructurado en 2 partes: 3 bits de precedence para codificar la
prioridad y 4 bits para codificar el type of service. Si este campo es utilizado para
Diffserv se emplean 6 bits, que codifican el DSCP (Differentiate Service Code Point)
según lo especificado por dicho estándar.
En lo relativo al plan de numeración, IPv4 es actualmente uno de los pilares que soporta
Internet, existiendo unas directrices claras para establecer dicho plan de numeración.
Cuando una red proporciona servicios a una colectividad específica de clientes, como es
el presente caso, desde el punto de vista de
Internet ésta forma una red privada y su plan de numeración tiene un espacio de
direccionamiento bien definido, de modo que:
 En el rango de direcciones clase A es 10/8.
 En el rango de direcciones clase B es 172.16/12.
 En el rango de direcciones clase C es 192.168/16.
El acceso de un cliente de esta red a Internet deberá hacerse con direcciones públicas.
En consecuencia, el espacio de direccionamiento privado contiene 16 millones de
direcciones IP posibles, lo cual es escaso si se considera que la eficiencia de la
asignación de direcciones a los clientes está condicionada por su distribución
geográfica, por lo que la eficiencia nunca será muy alta. Las técnicas de superneting y
de subnetting (en general, CIDR) permiten aprovechar mejor el espacio de
direccionamiento. En cualquier caso, éste y la movilidad IP son los únicos
inconvenientes que presenta actualmente IPv4.
En lo relativo a la numeración multicast la situación es similar, siendo el rango de
numeración privado 239.128/9. En este caso el espacio de numeración es
suficientemente amplio, ya que, a diferencia del direccionamiento unicast que identifica
las interfaces de acceso de cliente, en este caso se identifican flujos multicast.
El protocolo de routing unicast más adecuado en el troncal y la red de acceso es OSPF o
IS-IS, empleándose RIP en los anillos donde se encuentran conectados los clientes. Esto
permite simplificar el routing con RIP en la parte final de la red donde la estructura de
anillo propuesta así lo permite, debiendo tener en cuenta las restricciones de métrica que
impone dicho protocolo. Las rutas estáticas y las ip-policy también se emplearán en los
casos que se requiera para facilitar y simplificar el routing unicast.
El protocolo multicast mas adecuado es PIM, ya que ofrece ventajas frente al protocolo
DVMRP, que fue el primer protocolo desarrollado para el routing multicast, y además
actualmente ya existen distintos fabricantes que lo implementan. DVMRP no es
escalable y tiene severas limitaciones y desventajas que le hacen poco recomendable
para una red como la que se propone, especialmente en servicios que no sean de
distribución. Se emplea PIM en sus diferentes variantes: PIMDM, PIM-SM y PIM-SS,
junto con otros protocolos como MSDP que permiten aumentar la escalabilidad.
Para la gestión de direcciones multicast en la red y su asignación según los diferentes
servicios, siempre que los equipos lo soporten, se emplea la arquitectura MALLOC; ésta
emplea distintos protocolos para la gestión, asignación y reparto de direcciones
multicast en la red para su uso, ya sea temporal o permanente.
Como norma general, el rango de direcciones multicast a utilizar en la red se divide en
subrangos, cada uno de ellos reservado para el uso en un tipo de aplicaciones, lo cuál,
además de estructurar el direccionamiento, facilitará en gran medida las funciones de
seguridad (filtrado) en la red para el control de acceso a los servicios que utilizan
multicast.
PIM es el protocolo más apropiado, ya que soporta eficazmente el multicast en modo
denso (PIM-DM /
PIM-SS) y en modo disperso (PIM-SM). Esto es importante si se considera que en la
red coexisten ambos escenarios; así, la distribución de TV tiene un patrón de multicast
en modo denso, mientras que la multiconferencia o la distribución de información
corporativa tiene un comportamiento en modo disperso.
En el caso de conectarse a otras redes se deberán emplear protocolos tales como BGP,
MBGP y MSDP.
PROTOCOLO IPv6
IPv6 es la versión 6 del Protocolo de Internet (Internet Protocol), un estándar del nivel
de red encargado de dirigir y encaminar los paquetes a través de una red.
Diseñado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 está destinado a
sustituir al estándar IPv4, cuyo límite en el número de direcciones de red admisibles
está empezando a restringir el crecimiento de Internet y su uso, especialmente en China,
India, y otros países asiáticos densamente poblados. Pero el nuevo estándar mejorará el
servicio globalmente; por ejemplo, proporcionando a futuras celdas telefónicas y
dispositivos móviles con sus direcciones propias y permanentes. Al día de hoy se
calcula que las dos terceras partes de las direcciones que ofrece IPv4 ya están asignadas.
IPv4 soporta 4.294.967.296 (232) direcciones de red diferentes, un número inadecuado
para dar una dirección a cada persona del planeta, y mucho menos para cada coche,
teléfono, PDA o tostadora; mientras que IPv6 soporta
340.282.366.920.938.463.463.374.607.431.768.211.456 (2128 ó 340 sextillones)
direcciones —cerca de 4,3 × 1020 (430 trillones) direcciones por cada pulgada cuadrada
(6,7 × 1017 ó 670 mil billones direcciones/mm2) de la superficie de La Tierra.
Adoptado por el Internet Engineering Task Force en 1994 (cuando era llamado "IP Next
Generation" o IPng), IPv6 cuenta con un pequeño porcentaje de las direcciones públicas
de Internet, que todavía están dominadas por IPv4. La adopción de IPv6 ha sido frenada
por la traducción de direcciones de red (NAT), que alivia parcialmente el problema de
la falta de direcciones IP. Pero NAT hace difícil o imposible el uso de algunas
aplicaciones P2P, como son la voz sobre IP (VoIP) y juegos multiusuario. Además,
NAT rompe con la idea originaria de Internet donde todos pueden conectarse con todos.
Actualmente, el gran catalizador de IPv6 es la capacidad de ofrecer nuevos servicios,
como la movilidad, Calidad de Servicio (QoS), privacidad, etc.
Esta versión del protocolo IP tiene por objeto resolver las supuestas deficiencias de la
versión IPv4. No obstante, ya se ha analizado que de todas ellas sólo las relativas al
espacio de numeración y la movilidad IP son atribuibles al propio protocolo.
Los cambios más importantes del protocolo IPv6 son:
Definición de un campo traffic class de 4 bits y otro de flow label de 20 bits. Se puede
decir, en líneas generales, que sustituyen al campo ToS de 8 bits en IPv4, con objeto de
soportar QoS.
Ampliación de los campos de dirección a 16 bytes.
Integración de un modelo de seguridad dentro del propio protocolo IPv6.
Dispone de mecanismos de autoconfiguración (lo que supone una ventaja para el
usuario y el administrador de la red).
Dispone de mecanismos de movilidad (lo que permite al usuario cambiar físicamente de
interfaz de acceso a la red sin perder su identidad). Esta movilidad puede proporcionarse
tanto en redes fijas como móviles.
Por tanto, los problemas remanentes de IPv4 quedan resueltos en la versión IPv6.
Asimismo, los criterios para establecer el plan de numeración son similares a los ya
descritos para la versión IPv4, con la diferencia de que el número de clientes totales no
tiene restricciones.
En este caso se puede plantear la asignación de direcciones de clientes dentro del
espacio público de direcciones, lo cual soluciona la actual pretensión de asignar
direcciones IP de esta naturaleza a los terminales fijos y móviles de tercera generación.
Esto puede tener ventajas en lo que se refiere a la provisión de servicios prestados por
otras redes sobre una única dirección IP, aunque puede tener ciertos inconvenientes
relativos a la pérdida de seguridad de la red.
En IPv6, además de los mecanismos que permiten determinar las direcciones en IPv4
(manualmente y mediante DHCP), hay un nuevo mecanismo que permite hacerlo de
forma totalmente automática (stateless autoconfiguration). En este último, el host
obtiene la dirección a partir de un prefijo de 64 bits anunciado por el router (prefix
advertisement), junto con la información de su interfaz local, generando un identificador
de interfaz de 64 bits siguiendo el estándar EUI- 64. Para evitar que existan direcciones
duplicadas en una red se ejecuta un algoritmo de detección de direcciones duplicadas.
De forma más concreta, en este algoritmo, las direcciones se crean como tentative (no
definitivas) y, durante un tiempo, se envían mensajes en los que se solicita que se
informe si su dirección está duplicada.
Si no se reciben mensajes, su estado pasa de ser tentative a definitivo.
Otra característica importante de IPv6 es la movilidad
IP (Mobile IP). Ésta se consigue empleando túneles; los drivers para la configuración de
túneles están disponibles en todas las implementaciones del protocolo IPv6, en parte
debido a que los túneles son un mecanismo que permite la convivencia de IPv4 e IPv6
en la etapa de transición. El soporte de movilidad se empezó a desarrollar en IPv4 e
IPv6 al mismo tiempo, pero el grupo de trabajo correspondiente del
IETF llegó a la conclusión de que el soporte en IPv4 adolecía de problemas de
seguridad.
Los sistemas de acceso a redes IP denominados Always-on (como en el caso de la
RNG), en los que el usuario residencial y/o remoto está permanentemente conectado
con una dirección IP pública, son cada vez más frecuentes. El uso de direcciones
públicas no es un mero capricho de diseño, ya que el uso de direcciones privadas lleva
al uso de NATs o PROXYs, rompiendo la conectividad extremo a extremo e
introduciendo problemas de capacidad, especialmente en los sistemas de acceso de
banda ancha, como ADSL.
Debido a esto, estas redes incrementan la demanda de direcciones IP públicas a un ritmo
mayor del esperado, pues el acceso permanente impide una concentración de recursos
(las direcciones IP públicas), basado en la división por tiempo de uso de las mismas
(asignación dinámica). El problema se ve agravado porque algunos servicios o
mecanismos de red están basados en la asignación de varias direcciones públicas por
usuario.
El fuerte crecimiento actual de las redes de acceso de banda ancha, especialmente
ADSL y las redes de cable, augura una anticipación de la fecha límite en la que podrían
agotarse las direcciones IPv4 públicas.
Por tanto, se considera que éste puede ser un factor que desencadene el uso de
direcciones y, por tanto, del protocolo IPv6.
IPv6 ya hace tiempo que dejó de ser un protocolo teórico para pasar a ser un hecho. Hoy
en día existen multitud de redes IPv6 en todo el mundo, que se interconectan a través de
la red experimental 6-Bone.
Para facilitar la coexistencia de IPv6 con IPv4 existen una serie de mecanismos de
traducción y tunelado que permiten a los hosts IPv6 acceder a redes IPv4. La topología
más habitual, utilizando IPv6, consiste en una serie de redes de área local IPv6 que se
conectan a través de túneles sobre IPv4, ya sea con túneles manuales o bien túneles
6to4.
En la Figura 10 se muestra un escenario básico de IPv6, donde se ponen de manifiesto
la interrelación con el mundo IPv4 y los mecanismos de autoconfiguración y seguridad
propios de este protocolo. De todas maneras, la implantación comercial de esta versión
es todavía escasa, por lo que en una primera
fase el protocolo de red será IPv4, para pasar posteriormente a IPv6. Se debe considerar
que la implantación masiva de IPv6 puede tardar varios años, aunque existen diferentes
mecanismos que permiten la implantación progresiva de IPv6 en entornos IPv4,
utilizando técnicas de tunelado.

DIRECCIONAMIENTO IPv6
El cambio más drástico de IPv4 a IPv6 es la longitud de las direcciones de red.
Las direcciones IPv6, definidas en el RFC 2373 y RFC 2374, son de 128 bits; esto
corresponde a 32 dígitos hexadecimales, que se utilizan normalmente para escribir las
direcciones IPv6, como se describe en la siguiente sección. El número de direcciones
IPv6 posibles es de 2128 _ 3.4 x 1038. Este número puede también representarse como
1632, con 32 dígitos hexadecimales, cada uno de los cuales puede tomar 16 valores
(véase combinatoria).
En muchas ocasiones las direcciones IPv6 están compuestas por dos partes lógicas: un
prefijo de 64 bits y otra parte de 64 bits que corresponde al identificador de interfaz, que
casi siempre se genera automáticamente a partir de la dirección MAC de la interfaz a la
que está asignada la dirección.
Notación para las direcciones IPv6
Las direcciones IPv6, de 128 bits de longitud, se escriben como ocho grupos de cuatro
dígitos hexadecimales.
Por ejemplo,
2001:0db8:85a3:08d3:1319:8a2e:0370:7334 Es una dirección IPv6 válida.
Si un grupo de cuatro dígitos es nulo (es decir, toma el valor "0000"), puede ser
comprimido. Por ejemplo,
2001:0db8:85a3:0000:1319:8a2e:0370:7344 Es la misma dirección que
2001:0db8:85a3::1319:8a2e:0370:7344 Siguiendo esta regla, si más de dos grupos
consecutivos son nulos, pueden comprimirse como "::".
Si la dirección tiene más de una serie de grupos nulos consecutivos la compresión solo
en uno de ellos. Así,
2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab
Son todas válidas y significan lo mismo, pero 2001::25de::cade
Es inválido porque no queda claro cuantos grupos nulos hay en cada lado. Los ceros
iniciales en un grupo pueden ser omitidos. Así,
2001:0DB8:02de::0e13
Es lo mismo que 2001:DB8:2de::e13
Si la dirección es una dirección IPv4 camuflada, los últimos 32 bits pueden escribirse en
base decimal; así,
::ffff:192.168.89.9 es lo mismo que
::ffff:c0a8:5909, pero no lo mismo que
::192.168.89.9 o ::c0a8:5909.
El formato ::ffff:1.2.3.4 se denomina dirección IPv4 mapeada, y el formato ::1.2.3.4
dirección IPv4 compatible.
Las direcciones IPv4 pueden ser transformadas fácilmente al formato IPv6. Por
ejemplo, si la dirección decimal IPv4 es 135.75.43.52 (en hexadecimal, 0x874B2B34),
puede ser convertida a 0000:0000:0000:0000:0000:0000:874B:2B34 o ::874B:2B34.
Entonces, uno puede usar la notación mixta dirección IPv4 compatible, en cuyo caso la
dirección debería ser ::135.75.43.52. Este tipo de dirección IPv4 compatible casi no está
siendo utilizada en la práctica, aunque los estándares no la han declarado obsoleta.
Identificación de los tipos de direcciones
Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los primeros bits
de cada dirección.
 128 – la dirección con todo ceros se utiliza para indicar la ausencia de dirección,
y no se asigna ningún nodo.
 1/128 – la dirección de loopback es una dirección que puede usar un nodo para
enviarse paquetes a sí mismo (corresponde con 127.0.0.1 de IPv4). No puede
asignarse a ninguna interfaz física.
 96 – La dirección IPv4 compatible se usa como un mecanismo de transición en
las redes duales IPv4/IPv6. Es un mecanismo obsoleto.
 ffff:0:0/96 – La dirección IPv4 mapeada es usada como un mecanismo de
transición en terminales duales.
 fe80::/10 – El prefijo de enlace local (< inglés link local) específica que la
dirección sólo es válida en el enlace físico local.
 fec0::/10 – El prefijo de emplazamiento local (< inglés site-local prefix)
específica que la dirección sólo es válida dentro de una organización local. LA
RFC 3879 lo declaró obsoleto, estableciendo que los sistemas futuros no deben
implementar ningún soporte para este tipo de dirección especial.
 ff00::/8 – El prefijo de multicast es usado para las direcciones multicast. Hay
que resaltar que las direcciones de difusión (< inglés broadcast) no existen en
IPv6, aunque la funcionalidad que prestan puede emularse utilizando la
dirección multicast FF01::1, denominada todos los nodos (< inglés all nodes)
Paquetes IPv6
Estructura de la cabecera de un paquete IPv6.
Un paquete en IPv6 está compuesto principalmente de dos partes: la cabecera y los
datos.
La cabecera está en los primeros 40 bytes del paquete y contiene las direcciones de
origen y destino (128 bits cada una), la versión de IP (4 bits), la clase de tráfico (8 bits,
Prioridad del Paquete), etiqueta de flujo (20 bits, manejo de la Calidad de Servicio),
longitud del campo de datos (16 bits), cabecera siguiente (8 bits), y límite de saltos (8
bits, Tiempo de Vida). Después viene el campo de datos, con los datos que transporta el
paquete, que puede llegar a 64k de tamaño en el modo normal, o más con la opción
"jumbo payload".
Hay dos versiones de IPv6 levemente diferentes. La ahora obsoleta versión inicial,
descrita en el RFC 1883, difiere de la actual versión propuesta de estándar, descrita en
el RFC 2460, en dos campos: 4 bits han sido reasignados desde "etiqueta de flujo" (flow
label) a "clase de tráfico" (traffic class). El resto de diferencias son menores.
En IPv6 la fragmentación se realiza sólo en el nodo origen del paquete, al contrario que
en IPv4 en donde los routers pueden fragmentar un paquete. En IPv6, las opciones
también se salen de la cabecera estándar y son especificadas por el campo "Cabecera
Siguiente" (Next Header), similar en funcionalidad en IPv4 al campo Protocolo. Un
ejemplo: en IPv4 uno añadiría la opción "ruta fijada desde origen" (Strict Source and
Record Routing) a la cabecera IPv4 si quiere forzar una cierta ruta para el paquete, pero
en IPv6 uno modificaría el campo "Cabecera Siguiente" indicando que una cabecera de
encaminamiento es la siguiente en venir. La cabecera de encaminamiento podrá
entonces especificar la información adicional de encaminamiento para el paquete, e
indicar que, por ejemplo, la cabecera TCP será la siguiente. Este procedimiento es
análogo al de AH y ESP en IPsec para IPv4 (que aplica a IPv6 de igual modo, por
supuesto).
Cabeceras de extensión de IPv6
El uso de un formato flexible de cabeceras de extensión opcionales es una idea
innovadora que permite ir añadiendo funcionalidades de forma paulatina. Este diseño
aporta gran eficacia y flexibilidad ya que se pueden definir en cualquier momento a
medida que se vayan necesitando entre la cabecera fija y la carga útil.
Hasta el momento, existen 8 tipos de cabeceras de extensión, donde la cabecera fija y
las de extensión opcionales incluyen el campo de cabecera siguiente que identifica el
tipo de cabeceras de extensión que viene a continuación o el identificador del protocolo
de nivel superior. Luego las cabeceras de extensión se van encadenando utilizando el
campo de cabecera siguiente que aparece tanto en la cabecera fija como en cada una de
las citadas cabeceras de extensión. Como resultado de la secuencia anterior, dichas
cabeceras de extensión se tienen que procesar en el mismo orden en el que aparecen en
el datagrama. Todas o parte de estas cabeceras de extensión tienen que ubicarse en el
datagrama en el orden especificado:
1. Cabecera principal, tiene el contrario que la cabecera de la versión IPv4 un
tamaño fijo de 40 octetos.
2. Cabecera de opciones de salto a salto (Hop-by-Hop), transporta información
opcional, contiene los datos que deben ser examinado por cada nodo (cualquier
sistema con IPv6) a través de la ruta de envío de un paquete. Su código es 0.
3. Cabecera de encaminamiento (Routing), se utiliza en para que un origen IPv6
indique uno o más nodos intermedios que se han de visitar en el camino del
paquete hacia el destino. El código que utiliza es 43.
4. Encaminamiento desde la fuente.
5. Cabecera de fragmentación (Fragment), hace posible que el origen envíe un
paquete más grande de lo que cabría en la MTU de la ruta (unidad máxima de
transferencia). Hay que tener en cuenta que al contrario que en IPv4, en IPv6 la
fragmentación de un paquete solo se puede realizar en los nodos de origen. El
código empleado en esta cabecera es 44.
6. Cabecera de autenticación (Authentication Header), nos sirve para proveer
servicios de integridad de datos, autenticación del origen de los datos, antireplay
para IP. El código de esta cabecera es 51.
7. Cabecera de encapsulado de seguridad de la carga útil (Encapsulating Security
Payload), permiten proveer servicios de integridad de datos. El código al que
hace referencia esta cabecera es el 50.
8. Cabecera de opciones para el destino (Destination), se usa para llevar
información opcional que necesita ser examinada solamente por los nodos
destino del paquete. La última de las cabeceras utiliza el código 60.
Cada cabecera de extensión debe aparecer como mucho una sola vez, salvo la cabecera
de opción destino, que puede aparecer como mucho dos veces, una antes de la cabecera
encaminamiento y otra antes de la cabecera de la capa superior.

IPv6 y el Sistema de Nombres de Dominio


Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS)
mediante registros AAAA (también llamados registros de quad-A, por analogía con los
registros A para IPv4)
El concepto de AAAA fue una de las dos propuestas al tiempo que la arquitectura IPv6
estaba siendo diseñada. La otra propuesta utilizaba registros A6 y otras innovaciones
como las etiquetas de cadena de bits (bit-string labels) y los registros DNAME.
Mientras que la idea de AAAA es una simple generalización del DNS IPv4, la idea de
A6 fue una revisión y puesta a punto del DNS para ser más genérico, y de ahí su
complejidad.
La RFC 3363 recomienda utilizar registros AAAA hasta tanto se pruebe y estudie
exhaustivamente el uso de registros A6. La RFC 3364 realiza una comparación de las
ventajas y desventajas de cada tipo de registro.
Ventajas:
 Convivencia con IPv4, que hará posible una migración suave.
 Gran cantidad de direcciones, que hará virtualmente imposible que queden
agotadas. Se estima que si se repartiesen en toda la superficie de la Tierra habría
6,67x1023 IPs por m².
 Direcciones unicast, multicast y anycast.
 Formato de cabecera más flexible que en IPv4 para agilizar el encaminamiento.
 Nueva etiqueta de flujo para identificar paquetes de un mismo flujo.
 No se usa checksum.
 La fragmentación se realiza en el nodo origen y el reensamblado se realiza en los
nodos finales, y no en los routers como en IPv4.
 Nuevas características de seguridad. IPSEC formará parte del estándar.
 Nueva versión de ICMP, que incluye a MLD, el equivalente del IGMP de IPv4.
 Autoconfiguración de los nodos finales, que permite a un equipo aprender
automáticamente una dirección IPv6 al conectarse a la red.
 Movilidad incluida en el estándar, que permitirá cambiar de red sin perder la
conectividad.
Mecanismos de transición a IPv6
El cambio de IPv4 a IPv6 ya ha comenzado. Durante 20 años se espera que convivan
ambos protocolos y que la implantación de IPv6 sea paulatina. Existe una serie de
mecanismos que permitirán la convivencia y la migración progresiva tanto de las redes
como de los equipos de usuario. En general, los mecanismos de transición pueden
clasificarse en tres grupos:
 Pila dual
 Túneles
 Traducción
La pila dual hace referencia a una solución de nivel IP con pila dual (RFC 2893), que
implementa las pilas de ambos protocolos, IPv4 e IPv6, en cada nodo de la red. Cada
nodo de pila dual en la red tendrá dos direcciones de red, una IPv4 y otra IPv6.
 Pros: Fácil de desplegar y extensamente soportado.
 Contras: La topología de red requiere dos tablas de encaminamiento y dos
procesos de encaminamiento. Cada nodo en la red necesita tener actualizadas las
dos pilas.
Los túneles permiten conectarse a redes IPv6 "saltando" sobre redes IPv4.
Estos túneles trabajan encapsulando los paquetes IPv6 en paquetes IPv4 teniendo como
siguiente capa IP el protocolo número 41, y de ahí el nombre proto-41. De esta manera,
los paquetes IPv6 pueden ser enviados sobre una infraestructura IPv4. Hay muchas
tecnologías de túneles disponibles. La principal diferencia está en el método que usan
los nodos encapsuladores para determinar la dirección a la salida del túnel.
PROTOCOLO IP MÓVIL
El Protocolo IP Móvil define procedimientos por los cuales los paquetes pueden ser
enrutados a un nodo móvil, independientemente de su ubicación actual y sin cambiar su
dirección IP. Los paquetes destinados a un nodo móvil primeramente son dirigidos a su
red local. Allí, un agente local los intercepta y mediante un túnel los reenvía a la
dirección temporal recientemente informada por el nodo móvil. En el punto final del
túnel un agente foráneo recibe los paquetes y los entrega al nodo móvil.
Características de IP Móvil
 No posee limitaciones geográficas: un usuario podría usar su computadora
portátil (laptop, notebook, palmtop, etc.) en cualquier lugar sin perder conexión
a su red.
 No requiere conexión física: IP Móvil encuentra enrutadores (routers) y se
conecta automáticamente, sin necesidad de fichas telefónicas ni cables.
 No requiere modificar enrutadores ni terminales: a excepción del nodo o
enrutador móvil, los demás enrutadores y terminales permanecen usando su
dirección IP actual. IP Móvil no afecta a los protocolos de transporte ni a los
protocolos de más alto nivel.
 No requiere modificar las direcciones IP actuales ni su formato: las direcciones
IP actuales y sus formatos no varían.
 Soporta seguridad: utiliza mecanismos de autenticación para garantizar la
protección de los usuarios.
Funcionamiento del protocolo IP Móvil
El funcionamiento del protocolo IP Móvil consiste de varias operaciones:
Cuando un nodo móvil se encuentra lejos de su red local debe encontrar algún agente
para no perder conectividad a Internet. Existen dos caminos para encontrar agentes: uno
de ellos es seleccionando a un agente de movilidad captado a través de mensajes de
difusión que éstos emiten periódicamente advirtiendo su disponibilidad en cada enlace
en donde pueden proveer servicios; el otro camino es mediante la emisión de solicitudes
sobre el enlace, por parte del nodo móvil recientemente arribado, hasta obtener
respuesta de algún agente de movilidad que esté presente. Una vez encontrado el agente,
el nodo móvil deduce si se encuentra en su red local o en una red externa. Si se
encuentra en su red local opera sin servicios de movilidad, mientras que si se encuentra
en una red externa obtiene su dirección de auxilio que puede ser asignada
dinámicamente o asociada con su agente foráneo.
Una vez obtenida la dirección de auxilio, el nodo móvil debe registrarla con su agente
local para obtener servicios. El proceso de registración puede ser realizado a través de
una solicitud de registro enviada directamente desde el nodo móvil al agente local y
recibiendo de éste un mensaje de contestación, o indirectamente reenviada por el agente
foráneo al local, dependiendo de si la dirección de auxilio fue asignada dinámicamente
o asociada con su agente foráneo. Después del proceso de registración el nodo móvil
permanece en el área de servicio hasta que expire el tiempo de servicio otorgado o hasta
que cambie su punto de enlace a la red. Durante este tiempo el nodo móvil obtiene
paquetes reenviados por el agente foráneo, los cuales fueron originalmente enviados
desde el agente local. El método túnel (tunneling) es usado para reenviar los mensajes
desde el agente local al agente foráneo y finalmente al nodo móvil.
Después de que el nodo móvil regresa a su red, se desregistra con su agente local para
dejar sin efecto su dirección de auxilio, enviando un requerimiento de registración con
tiempo de vida igual a cero. El nodo móvil no necesita desregistrarse del agente foráneo
dado que el servicio expira automáticamente cuando finalizar el tiempo de servicio.
“El protocolo Mobile IP es entendido mejor como la cooperación de tres mecanismos
separables: Discovering the care-of address, Registering the careof address, Tunneling
to the care-of address.”.
Servicios
Descubrimiento de Agente (Agent Discover)
Los agentes locales y foráneos emiten mensajes de difusión (broadcast), llamados
avisos de agente (agent advertisements), advirtiendo periódicamente su presencia en
cada enlace en donde pueden proveer servicios. Los nodos móviles escuchan estos
avisos y determinan si están conectados o no a su red local. Además, un nodo móvil
recientemente arribado a una red podría enviar una solicitud para saber si un agente de
movilidad está presente y forzarlo a que inmediatamente envíe un aviso de agente. Si un
nodo móvil determina que se encuentra conectado a un enlace foráneo, adquiere una
dirección de auxilio.
Registración (Registration) Una vez que el nodo móvil adquiere una dirección de
auxilio, debe registrarla con su agente local, para que el agente local sepa a dónde
reenviar sus paquetes o proveerle servicio. Dependiendo de la configuración de la red,
el nodo móvil podría registrarse directamente con su agente local o indirectamente
mediante la ayuda de un agente foráneo.
Encapsulamiento (Encapsulation) Proceso de encerrar a un paquete IP dentro de otro
encabezado IP, el cual contiene la dirección de auxilio del nodo móvil. Durante el
proceso de encapsulación el paquete IP no es modificado.
Desencapsulamiento Proceso de despojar el encabezado IP de más afuera del paquete
entrante para que el paquete encerrado dentro de él pueda ser accedido y entregado al
destino apropiado.

EL PROTOCOLO MPLS
Este protocolo nace como una necesidad de integrar las distintas soluciones propietarias
de conmutación de alta velocidad basadas en equipos ATM para redes IP (tag-
switching, etc.). Actualmente ha evolucionado, buscando dar respuesta a alguno de los
puntos especialmente criticados de las redes IP, por ejemplo, aportando mecanismos
para resolver aspectos de ingeniería de tráfico. Además, aparece como una buena opción
para resolver parte de los problemas encontrados en las soluciones clásicas de VPN,
como, por ejemplo, la gestión, el provisionamiento y la escalabilidad, con la ventaja de
que este tipo de soluciones para VPN han sido ya estandarizadas y son soportadas
actualmente por varios de los fabricantes más importantes de equipos de red.
Sin embargo MPLS no está libre de problemas, ya que al basarse de nuevo en el
establecimiento de circuitos virtuales, choca frontalmente con otros protocolos y
soluciones existentes en el mundo IP. Para el entorno de la RNG, un problema actual de
MPLS se deriva de la inexistencia de soluciones estándar que permitan trabajar
conjuntamente a los protocolos de routing multicast y MPLS de forma integrada, ya que
actualmente pueden funcionar sobre la misma red, pero de manera independiente y sin
relación funcional entre ellos.
La única solución a este punto es que los protocolos de routing multicast trabajen de
forma independiente respecto de MPLS, y dentro del troncal de la red se encarguen de
definir distintos LSPs o caminos MPLS sobre los cuales se encaminen los diferentes
flujo multicast. Cabe destacar que el tráfico o flujo multicast que mejor se adapta para
su uso con MPLS es el correspondiente a los servicios de distribución. En otros
servicios como el de multiconferencia sería inviable su uso, debido al dinamismo
inherente al propio servicio, al crearse y anularse de forma continua y rápida gran
cantidad de árboles multicast, lo que implicaría un dinamismo similar para la activación
y desactivación de caminos LSPs de MPLS. Desde el punto de vista de ingeniería de
tráfico, el modelo de RNG descrito hasta ahora no necesita mecanismos adicionales que
optimicen la distribución del tráfico en la red, de forma que la probabilidad de que se
congestione algún enlace es pequeña.
Las características que hacen esto posible son las siguientes:
 Se trata de una red de nueva creación, no dependiendo, por tanto, de una
topología y dimensionamiento, legado que, en principio, no suele estar adaptado
al tráfico generado por los servicios multimedia que se piensan proveer a corto y
medio plazo.
 El tráfico se puede estimar, estando tipificado con un modelo de Erlang en
servicios como VoIP, distribución de TV, VoD y multiconferencia, que son los
que aportarían la mayoría del tráfico cursado.
 Se utiliza el estandar de QoS Diffserv.
 La topología es redundante y está estructurada en doble plano.
 Está dimensionada teniendo en cuenta los tráficos que debe soportar. Cada uno
de los planos es capaz de soportar dicho tráfico, de forma que ante un fallo
simple en la red se siguen soportando los servicios descritos.
 Se emplean SLAs en el acceso.
Teniendo en cuenta estos factores, en principio no es necesaria la inclusión de
elementos de ingeniería de tráfico en la gestión de la red. Sin embargo, puede que
debido a modificaciones en las características del tráfico (por ejemplo, transporte de
otro tipo de tráfico sobre el troncal, etc.), en algún momento se hiciera necesario aplicar
algún criterio especial a alguno de los flujos transportados por la red, optimizando la
ocupación de los recursos de red (transmisión y/oconmutación).
La solución más sencilla es pensar en mecanismos implementados a nivel IP, bien por
los propios protocolos (métricas, rutas estáticas y ECMP), o bien por los equipos (ip
policy). Esta solución también es la más económica, puesto que no obliga a la inclusión
de ningún otro protocolo en los equipos, aunque es la más dependiente del fabricante, ya
que la funcionalidad disponible, aunque muy parecida, no es totalmente similar. El
problema de esta solución es que es poco manejable y no escala para redes grandes.
Otra solución es la inclusión en la red de nuevos protocolos destinados específicamente
a cubrir esta necesidad, como es el caso de MPLS. Éste permite la creación de caminos
LSPs explícitos, caminos basados en condiciones y caminos múltiples, que junto con
otras facilidades de MPLS, como el fast-reroute y hot standby, facilitan y automatizan
en gran medida la ingeniería de tráfico. En concreto, estas dos últimas facilidades
permiten la recuperación ante fallos (transmisión y/o conmutación) en tiempos
comparables a los de JDS.

CONCLUSIONES

El modelo de RNG propuesto permite materializa los nuevos conceptos que han
aparecido en el mercado para una red IP multiservicio de banda ancha, red que facilita
al operador la provisión a los clientes finales de todo tipo de servicios multimedia con
una relación prestación/coste muy competitiva comparada con las soluciones clásicas
de red.
El transporte se realiza en modo datagrama (IP) extremo a extremo, utilizando
direccionamiento unicast y multicast, consiguiendo con ello la agregación de todo tipo
de tráfico, independientemente del tipo de servicio, y permitiendo la provisión de
servicios punto a multipunto, como la distribución de TV o el NVoD, y multipunto a
multipunto, como la multiconferencia, de una forma altamente escalable, sencilla y
barata. En el nivel 2 se propone fundamentalmente el uso de Ethernet, ya que
comparado con otras tecnologías como ATM o JDS su relación capacidad/coste es de
uno a dos ordenes de magnitud menor. El ámbito de aplicación de Ethernet ha pasado de
ser la típica LAN corporativa a abarcar mayores distancias, pudiéndose utilizar en
escenarios de MAN, WAN y la última milla, de forma que se puede hablar ya de
Ethernet en toda la comunicación extremo a extremo.
Desde el punto de vista de la QoS se plantea la jerarquización del tráfico en diferentes
prioridades, tal como se recoge en el estándar DiffServ, y el uso de SLAs en la periferia
de la red, lo que permite preservar la eficacia de ésta y poder disponer de un modelo
sencillo de ingeniería de red.
De todas formas, es necesario comentar que en las fases intermedias del proceso de
evolución hacia este modelo de RNG será imprescindible usar el protocolo MPLS, con
el objetivo de solucionar la provisión de ciertos servicios, como son las VPN, y facilitar
la resolución de problemas que puedan aparecer en la ingeniería de tráfico, a costa, claro
está, de perder la capacidad de proveer de forma eficaz servicios basados en el
transporte multicast.

También podría gustarte