Introduccion A Las Redes de Nueva Genera
Introduccion A Las Redes de Nueva Genera
Introduccion A Las Redes de Nueva Genera
CODIGO:062106
EVOLUCIOÓN EN ENTORNO IP
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 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).
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.
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.
Además deberá de disponer de ciertos elementos indispensables para que pueda ser
considerada como una Red de Nueva Generacion:
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).
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.
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.