TEMA 3 VPN – OPENVPN

INTRODUCCIÓN A LAS VPN

• Una VPN (Virtual Private Network) es una extensión de una red privada que proporciona un servicio de
enlace entre dos segmentos de la red privada a través de una red compartida o pública como, por
ejemplo, Internet.
• Permite el envío de datos entre dos equipos a través de la red pública con una funcionalidad similar a la
de un enlace punto a punto.
• Una posible clasificación de las VPN es en base al nivel (Nivel 3, 2 o 1) de la torre de protocolos al que
dan servicio.
• Es habitual también clasificarlas en base al nivel (Aplicación, Transporte, Red o Enlace) en el que operan
las tecnologías que se utilizan para implementarlas y al tipo de red (p.e. IP o MPLS)
• En este tema VPN de nivel 2 (Ethernet) y 3 (IP) que usan redes de Transporte basadas en protocolos IP.

CONEXIÓN DE VPN

• El PC cliente presenta una situación virtual equivalente a estar directamente conectado a la red privada.
• Para emular un enlace punto a punto entre cliente y servidor, los datos son encapsulados con una
cabecera que proporciona información de enrutado para atravesar la red compartida.
• Los datos además son cifrados para que al atravesar la red pública se haga de manera confidencial.
• Si se captura un paquete de estos
datos en la red pública su
contenido es “indescifrable” sin
conocer la clave de cifrado

ELEMENTOS DE UNA VPN

❖ Túnel: parte de la conexión en la que los datos privados son encapsulados.

❖ VPN: parte de la conexión en la cual los datos privados son cifrados.
❖ Cliente: elemento que consigue la conectividad usando la funcionalidad de la VPN.
❖ Servidor: elemento que proporciona la funcionalidad para la creación de la VPN.

1
USOS COMUNES DE LAS VPN

ACCESO REMOTO USANDO INTERNET

❖ También conocida como VPN Road Warrior.

❖ Proporciona acceso seguro a los recursos
de una organización usando la Internet
pública.
❖ Internet actúa de red de tránsito.
❖ La conexión a Internet se realiza a través de
un ISP (Internet Service Provider).
❖ Sobre la conexión del ISP, cliente y servidor
crean la VPN.

INTERCONEXIÓN DE REDES MEDIANTE INTERNET (SITE TO SITE)

Permite interconectar subsedes de una organización mediante una VPN.

Se pueden usar varios métodos:
❖ Líneas dedicadas. (Histórico)
Muy caro si se utiliza para
enlazar las sucursales. Más
apropiado para enlazar la sede
central con el ISP
❖ Líneas de dial-up. Si el tráfico es
intermitente puede usarse este
tipo de líneas.
❖ Ambas han caído en desuso
con la introducción del ADSL y
la fibra óptica.

CONEXIÓN DE ORDENADORES A TRAVÉS DE UNA INTRANET

❖ En algunas organizaciones interesa en ocasiones aislar

el tráfico de determinados departamentos por
cuestiones de seguridad y/o confidencialidad.
❖ Esto puede conseguirse trazando una o varias VPN a
través de la red corporativa.
❖ Los ordenadores implicados pueden participar en
diferentes redes a la vez.

CREACIÓN DE REDES WI-FI SEGURAS

❖ Esquema similar al anterior, en el que se

traza una VPN a través de una red (intranet Wi-
Fi) no segura hasta la red segura de la
organización.
❖ Los puntos de acceso están configurados en
modo infraestructura.
❖ La intranet Wi-Fi no ofrece recurso alguno,
proporcionando únicamente un mecanismo de
interconexión de los puntos de acceso y el
Servidor de VPN.

2
REQUISITOS BÁSICOS DE UNA VPN

❖ Mecanismo de transferencia fiable. A través de una red de transporte, usando túneles.

❖ Autenticación de usuario. PPTP y L2TP heredan los métodos básicos de PPP. OpenVPN usa los
proporcionados por SSL/TLS.
❖ Asignación de Direcciones. Se puede hacer de forma fija o usando DHCP.
❖ Compresión de datos.
❖ Cifrado de Datos. La implementación de Microsoft de PPTP usa MPPE (Microsoft Point-to-Point
Encryption) basada en el algoritmo RSA/RC4. La implementación de L2TP usa cifrado IPSec. OpenVPN
usa SSL/TLS.
❖ Gestión de claves. Define como se crean, almacenan, distribuyen, usan, etc. las claves usadas en la
sesión de VPN.

TÚNELES

❖ Un túnel es un método que proporciona una infraestructura de transferencia de datos sobre una red
preexistente.
❖ Los datos a transferir no han de compartir necesariamente los protocolos de la red de transporte.
❖ Los datos son cifrados y encapsulados en el origen, realizándose las operaciones inversas en el destino.
❖ El encapsulado proporciona información del camino lógico que han de seguir los paquetes entre fuente
y destino.
❖ Dicho camino lógico recibe el nombre de túnel. El tuneado suele incluir únicamente los procesos de
encapsulado, transmisión y desencapsulado

TECNOLOGÍAS DE TUNELADO
❖ Layer 2 Tunneling Protocol (L2TP): proporciona un servicio para que tráfico multiprotocolo sea cifrado y
después enviado mediante cualquier transporte que soporte envío de datagramas punto a punto, tal
como IP, X.25, Frame Relay o ATM.
❖ Túnel IPSec: permite que paquetes IP sean cifrados y encapsulados con una (otra) cabecera IP para ser
enviados mediante una red IP.
❖ Túnel SSL/TLS. Usados por OpenVPN.
❖ Túnel SSH. Solución simple de tunelado con cifrado.

POINT-TO-POINT PROTOCOL (PPP)

- Como PPTP y L2TP dependen fuertemente de las características desarrolladas para PPP es importante
conocer el funcionamiento básico de éste.
- Se distinguen cuatro fases que han de ser superadas por parte del cliente y del NAS (Network Access
Server) antes de entrar en la fase de transferencia de datos:
o Fase 1. Establecimiento del enlace PPP.
o Fase 2. Autenticación de usuario.
o Fase 3. Control de retrollamada PPP.
o Fase 4. Invocación de protocolos de control del nivel de red (IPCP, MPPC, MPPE…)

PPTP

❖ Los datagramas IP son encapsulados en tramas PPP.

❖ PPTP usa una conexión TCP para el control del túnel y GRE (Generic Routing Encapsulation) para
encapsular las tramas PPP por túneles de datos.
❖ La carga útil puede ser comprimida y/o cifrada.
❖ PPTP se describe en la RFC 2637

3
L2TP

❖ L2TP es una combinación de PPTP y L2F (Layer 2 Forwarding) de Cisco. L2TP encapsula tramas PPP para
ser enviadas sobre IP, X.25, FR y ATM.
❖ L2TP sobre IP usa UDP y un conjunto de mensajes L2TP para la gestión del túnel. Las tramas PPP
encapsuladas viajan igualmente sobre UDP tal como muestra la figura.

L2TP/IPSEC

❖ Protocolo IPsec Encapsulating Security Payload (ESP) para el cifrado del tráfico.
❖ La combinación de L2TP (protocolo de túnel) e IPsec (método de cifrado) se conoce como L2TP/IPsec y
se describe en la RFC 3193.
❖ Usa el protocolo IKE (Internet Key Exchange protocol) para el intercambio de claves.

VENTAJAS DE L2TP/IPSEC SOBRE PPTP

❖ IPSec ESP proporciona, por cada paquete de datos, autenticación de origen, prueba de integridad (los
datos no han sido modificados), protección de reenvío (los datos no han sido capturados, leídos y
reenviados) y confidencialidad del contenido. PPTP proporciona únicamente confidencialidad.
❖ L2TP/IPSec proporciona una autenticación más fuerte que PPTP, dado que además de autenticar al
usuario autentica a la máquina mediante certificado.
❖ Los paquetes de autenticación de PPTP no van cifrados, los de L2TP/IPSec sí.

OPENVPN

❖ Creado por James Yonan para uso personal.

❖ Basado en Open SSL.
❖ Doble licencia:
o Community edition: GPL v2
o Commercial edition.
❖ Historial de versiones.
o Mayo 2001. v0.9 primera versión
distribuida
o Febrero 2024. V2.6.9 (Community
Downloads)
❖ Disponible para: Linux, Solaris, *BSD, Windows
(XP.. 7, 8, 10 y Mobile), MAC OS, Android,
Iphone…
❖ Existe disponibilidad de VPN Server Appliances.
❖ Se crea una interfaz de red virtual TAP (Bridged,
Layer 2, Eth. frames) o TUN (Routed, Layer 3, IP
packets).
❖ Puede trabajar sobre TCP o UDP.
❖ Soporta todas las configuraciones de VPN vistas hasta el momento.

4
SERVIDOR DE OPENVPN SIMPL. INSTALACIÓN EN EL ELEMENTO DE ACCESO A UNA RED PRIVADA

INSTALACIÓN DE OPENVPN FUERA DEL ELEMENTO DE ACCESO A UNA RED PRIVADA

ARQUITECTURA DE OPENVPN

❖ Pese a poder usar TCP y UDP, se suele usar más UDP (puerto 1194) debido a
que le afecta menos la congestión.
❖ En ocasiones es obligatorio usar TCP, al tener que salir por un proxy HTTP. En
otras el puerto TCP 443 (HTTP over SSL/TLS) puede ser la única vía
accesible.
❖ Se soportan dos modos de autenticación:
o Static pre-shared keys
o SSL/TLS con certificados.
❖ Si se usa UDP, OpenVPN proporciona un nivel de transporte fiable.

5
TEMA 4: SDN Y NFV

INTRODUCCIÓN

Redes convencionales: tres planos en cada elemento de red

- Plano de forwarding (aka “plano de datos”)

o Elementos que realmente procesan los paquetes entrantes y salientes (puertos, buffers, tablas
de conmutación o encaminamiento, firmware o software que directamente procesa las
unidades de datos…)
- Plano de control:
o Modifica el comportamiento del plano de forwarding. Tradicionalmente distribuido.
o Ejemplo: Protoclo de encaminamiento OSPF, que causa que las tablas de encaminamiento del
equipo se vayan llenando
o No cambia la configuración del elemento de red (configuración de los puertos…)
- Plano de gestión: cambia la configuración. Ejemplos “tradicionales”:
o Conectarse mediante SSH a un equipo y configurarlo mediante CLI.
o SNMP (utilizado principalmente para obtener estado de los dispositivos, no tanto para
configurarlos).

Tendencias actuales en networking:

- Sistemas operativos de red sobre “open hardware”

- Network programmability and automation
o Interfaces de configuración de más alto nivel que el CLI: NETCONF, RESTCONF, REST APIs, gNMI
o YANG: Modelado de configuración y estado de elementos de red
o CI/CD y DevOps en sistemas de red
o Programación en lenguajes de alto nivel
- Análisis y diagnóstico de redes (“network monitoring and analytics”)
- Software Defined Networking (nos centraremos en el marco definido por el ONF)
- Network Functions Virtualization (impulsado por ETSI)

Sistemas operativos de red sobre “open hardware”:

o “Rotura” del monolito HW – OS – Apps (Este concepto no es nada nuevo en el mundo de la
informática)
o Sistemas operativos de red sobre HW “bare metal” o “white box switches”. Ejemplos:

▪
Network programmability and automation
- Permite al operador programar tareas de red de manera “human readable” y “vendor neutral”.
- Las tareas se llevan a cabo con menos intervención humana. Ejemplo: gestión de configuraciones.
Algunas ventajas:
▪ Despliegue más rápido de nuevas configuraciones.
▪ Resultados más predecibles y deterministas.
▪ Diagnóstico de fallos “habituales” mejorado.
▪ Mejor documentación.
▪ Facilita la introducción de AI/ML.
▪ Menores costes de operación.
▪ Ejemplo de producto: Ansible
Ansible
o Inicialmente pensado para automatización de servidores Linux:
▪ Scripts Python copiados a servidores para ser ejecutados.
o Para automatizar elementos de red, los scripts Python se ejecutan localmente.

6
 ▪ Ejemplo: la conexión con los equipos de red es SSH y sobre ella se envían las órdenes
CLI
o Ansible Playbooks: los ficheros que contienen los datos para lograr la automatización se
escriben en YAML

Algunos aspectos comunes

• Tendencia a sistemas abiertos
o Open source software
o Open hardware
o Linux
• No es tan fácil para operadores con mucho sistema desplegado (“legacy systems”, que deben mantener
a medio plazo) que para operadores con despliegues desde cero (“greenfield”), pero para ambos
pueden traer beneficios
• Un ingeniero de red no es un programador, pero deberá saber de programación (de alto nivel) e
integrarse con equipos que contienen programadores. Además de seguir sabiendo de redes.

SOFTWARE DEFINED NETWORKING SDN

- Def.- The physical separation of the network control plane from the forwarding plane, and where a
control plane controls several devices.

Figure 1. Foundations of Modern Networking:

7
Ventajas: Posibles desventajas:
Un control centralizado tiene riesgos:
- Visión centralizada de la red facilita algunas - Posible cuello de botella -- cuidado al escalar.
apps  Abstracción de detalles de bajo nivel - Se debe evitar tener un SPOF (“single point of
- Introducción de cambios y actualizaciones en failure”).
las apps más rápido (software) - Reacción en tiempo real a eventos o fallos se
- Independencia HW – SW (no dependencia de dificulta
fabricantes concretos) y estándares abiertos Para evitarlos:
- Hay controladores que permiten formar
clusters coordinados.
- Escenarios híbridos con OpenFlow + parte del
control distribuido

SDN – SWITCHES

- Solo SDN o híbridos:

o Entorno SDN puro: switches sin inteligencia.
o Entorno híbrido: switches que pueden operar bajo las órdenes de un controlador y también de
manera convencional (ej. en distintos puertos, o para distintas VLAN).
- Físicos o virtuales. Ejemplos:
o Grandes fabricantes: HP, Cisco, Huawei, Juniper Networks
o SO para HW “white box” o switches virtuales: Pica8, Open vSwitch, Stratum (NG-SDN)

SDN – CONTROLADORES

- Soportan distintos conjuntos de protocolos SBI, NBI,

distintos lenguajes de programación, …
- Habitualmente con estructura modular que permiten que se extiendan sus capacidades
- Los más conocidos son Open Source: ONOS, OpenDaylight (ODL),
- También hay ofertas comerciales, muchas veces basadas en alguno de los controladores Open Source

OPENFLOW

ESPECIFICACIÓN OPENFLOW
La especificación describe dos cosas:
- Arquitectura lógica de un switch OF
- Protoclo (OpenFlow switch protocol ) SBI que permite actuar sobre el plano de datos de un switch con
esa arquitectura.
- Última versión: 1.5.1 (0x06)
o No todas las versiones están soportadas por todos los switches o controladores: acuerdan la
versión al inicio de la comunicación
OPENFLOW SWITCH PROTOCOL
- Es un protocolo de SBI
- Actúa sobre el plano de datos (arquitectura lógica del switch)
a modo de plano de control
o No gestiona la configuración de los equipos.
▪ Para esto se pueden usar otros protocolos ej.
NETCONF, OVSDB u OF-Config
LÓGICA DE SWITCH OPENFLOW
- Datapath: Conjunto de elementos directamente involucrados
en el reenvío y procesado del tráfico
- Control channel: Permite a uno o varios controladores actuar
sobre el datapath
o Un “OpenFlow channel” por cada controlador con el
que el switch se comunica

8
SWITCH OF: PUERTOS
- No necesariamente hay equivalencia 1-a-1 entre puertos físicos del switch y puertos OF
- Ingress port: puerto por el que llegó un paquete. Propiedad que se mantiene durante su
procesamiento en el pipeline.
- Tres tipos de puertos:
o Físicos: Corresponden a interfaces hardware.
o Lógicos: Abstracciones de más alto nivel, ej. interfaz Loopback o túneles. Desde el punto de
vista de procesamiento OF, se comportan como los físicos.
o Reservados: Especifican acciones específicas de reenvío (ej. flooding o reenvío mediante
mecanismos no-OF)
PUERTOS RESERVADOS (algunos)
- All
o Representa todos los puertos por los que se puede enviar un paquete
o Solo puede ser puerto de salida (output) - se excluye el “ingress port” del paquete.
- Controller
o Representa el canal de control (control channel) con los controladores
o Si es output: encapsular el paquete en un PACKET_IN de OpenFlow y enviarlo al controlador
o Si es input: paquete originado en el controlador (recibido mediante PACKET_OUT)
- Table
o Representa el inicio del “pipeline” (primera tabla de flujos), para seguir el procesamiento regular
o Solo output en la lista de acciones de un PACKET_OUT desde el controlador
- Any
o Valor especial utilizado cuando no se quiere especificar un puerto concreto (“wildcarded port”).
- Normal
o Representa reenvío utilizando los métodos “no-OpenFlow” del switch (opcional, solo lo
soportan los switches híbridos)
SWITCH OF: PIPELINE

- Mínimo que debe tener un switch: una única tabla ingress.

- No se permiten bucles: procesamiento siempre con número de tabla creciente.
TABLA DE FLUJOS (FLOW TABLE)
- Cada tabla contiene entradas de flujo (flow entries) con los siguientes campos:

- Un paquete se procesa según una sola entrada (máx) de cada tabla:

o De entre las que coinciden los “match fields” con el paquete, la de mayor prioridad
o Entrada coincidente → actualizar contadores && ejecutar instrucciones
- Entrada “table-miss”: todos los “match fields” son “wildcard”, y su prioridad es 0.
o Es una manera de especificar acciones “por defecto” en la tabla.
- Si la entrada “table-miss” no existe y un paquete no encaja con ninguna entrada de la tabla, se descarta
(“drop”).

9
MATCH FIELDS: “CLASIFICADORES” EN FLUJOS
- Incluyen:
o Campos de cabeceras
o Campos del “pipeline” (otros campos que se adjuntan al paquete)
▪ Ingress port; Metadatos; Tunnel-ID (solo puertos lógicos); Output port (solo en la etapa
“egress processing”).
- Dependiendo del campo, se pueden usar máscaras y si el campo no está, se asume el valor ANY
- El paquete coincide con la entrada si todos los “match fields” del flujo coinciden con los
correspondientes valores del paquete y pipeline
- Ejemplos de campos de cabeceras:
o Protocolo encapsulado en Ethernet (Ethertype); VLAN-ID; Direcciones IPv4, IPv6

10
Action set Lista de acciones
• Asociado a cada paquete mientras el paquete • Las acciones de una lista se ejecutan
atraviesa el pipeline inmediatamente y en el orden en el que
• Máximo 1 acción de cada tipo, y se aplican en están en la lista (no hay orden
un orden determinado predeterminado)
• Se puede ir modificando conforme se • Se pueden repetir acciones
atraviesan tablas mediante las instrucciones: o Útil por ej. para hacer “push” de dos
•Write-Actions (si en el set hay acciones del etiquetas MPLS
mismo tipo, las nuevas reescriben las ya • Una vez ejecutadas, el paquete
existentes) (posiblemente modificado) continúa su
.Clear-Actions procesamiento en el pipeline
• Las acciones no se ejecutan inmediatamente, • Una lista de acciones se encuentra en:
sino tras la última tabla que atraviesa el o Instrucción “Apply-Actions”
paquete (cuando no hay instrucción Goto- o PACKET_OUT desde el controlador
Table)

GROUP TABLE
- Tabla que contiene entradas de grupo:

- Las acciones de un “Action Bucket” se aplican como un “Action set”. Habitualmente modifican el
paquete + lo reenvían por un puerto
- Múltiples entradas de flujo pueden apuntar al mismo grupo
- Se pueden encadenar entradas de grupo
- Ejemplos de tipos de grupo:
o Indirect: ejecutar su único Action Bucket. Ejemplo de utilidad: cambiar de manera eficiente
acciones comunes a varias entradas de flujo
o All: ejecutar todos los Action Buckets (el paquete se clona para cada bucket). Ejemplo de uso:
multicast o broadcast
INGRESS VS EGRESS PROCESSING
- Egress processing: procesamiento en el contexto de un puerto de salida.
o Aparece con la versión 1.5.0 del protocolo
o No es necesario utilizarlo (puede no tener ninguna tabla)
- Procesamiento a través de las tablas muy similar en ingress y en egress, excepto:
o En Egress, el “Action Set” no comienza vacío sino con la acción “Output” (con el puerto actual)
o En Egress, no se puede añadir ni “Output” ni “Group” al Action Set del paquete
TABLA DE MEDIDORES
- Se soportan medidores sencillos para los que se definen bandas de tasas
o En cada banda se define cómo procesar el paquete: drop (descartar) o remarcar DSCP
o Por tanto, es básicamente medidor + función policía
- Varios flujos de la misma tabla pueden apuntar al mismo medidor
- Se puede combinar con las colas por puerto para lograr un esquema de QoS de tipo DiffServ.
- Ejemplo de uso [OpenFlow15]:

11
PROTOCOLO OPENFLOW
Canal OpenFlow:
- OpenFlow sobre TLS (transporte seguro y fiable, recomendado) o sobre TCP (transporte fiable)
o La conexión (habitualmente) la inicia el switch, con el controlador que tiene configurado
(ej. tls: [Link])
o Posibilidad de varios canales con varios controladores (alta disponibilidad / escalabilidad) 
Tres tipos de mensajes:
- Controller-to-switch (iniciado por controlador, pueden requerir respuesta)
o Manipular o inspeccionar el estado del switch
- Asynchronous (enviados por switch sin petición previa del controlador)
o Notificar al controlador sobre eventos y cambios en el estado del switch
- Symmetric (enviados por switch o controlador sin solicitud previa)
o Inicio de conexión, verificación de conexión activa, errores en la conexión
CABECERA

INICIO DE CONEXIÓN OPENFLOW

EJEMPLO INTERCAMBIO DE MENSAJES

12
BARRIER REQUEST / REPLY
- Un switch puede aplicar las órdenes recibidas del controlador en orden distinto al de su recepción (ej.
para mejorar rendimiento)
- Como excepción, un switch no puede reordenar órdenes saltándose un BARRIER_REQUEST
o Debe ejecutar todas las órdenes recibidas antes del BARRIER_REQ., incluyendo enviar las
correspondientes respuestas si necesario y modificar el estado del Datapath
▪ Solo cuando esto esté finalizado, el switch envía al controlador BARRIER_REPLY en
respuesta al REQUEST (con su mismo xid)
o Esto permite al controlador establecer puntos de control para asegurar por ej. que ciertas
órdenes se aplican antes que otras

MENSAJES MULTIPART
- El tamaño máximo de un mensaje OpenFlow es 64KB
- Hay peticiones o respuestas que potencialmene exceden ese tamaño (típicamente solicitudes de
estadísticas o información de estado al switch)→ se codifican en una secuencia de mensajes multipart
que se reensamblan en el receptor
- El tipo en la cabecera OpenFlow es OFPT_MULTIPART_REQUEST o OFPT_MULTIPART_REPLY y el
“multipart type” determina de qué petición o respuesta concreta se trata:
o OFPMP_FLOW_DESC, OFPMP_AGGREGATE_STATS, OFPMP_TABLE_STATS,
OFPMP_PORT_STATS, OFPMP_PORT_DESC, OFPMP_FLOW_STATS, …

NETWORK FUNCTIONS VIRTUALIZATION NFV

Redes tradicionales:
- HW-SW integrado.
- Equipos específicamente adaptados para las funciones a desempeñar (ej. Firewall).
Limitaciones:
- Escalabilidad: potencia, espacio físico → barreras para la actualización y escalado → en ocasiones se
sobreprovisionan los recursos para alargar su vida útil (menor ROI).
- Time-to-market: introducir nuevos servicios y funcionalidades requiere adquirir / actualizar
equipamiento y a veces repensar el diseño de la red.
- Costes de operación: si hay equipos de varios fabricantes, su gestión y operación es más compleja.
NFV ≠ Redes virtuales
- Las redes virtuales proporcionan servicios de comunicación aislados que se comportan como redes
separadas pero que realmente comparten una infraestructura dedicada.
o Se pueden ver como redes superpuestas (overlay networks)
- Ejemplo de redes virtuales:  VLAN  VPN (de distintos niveles, ej.: L3, L2)

DEFINICIÓN
- Virtualización de funciones de red, utilizando la experiencia ya consolidada de la virtualización de
servidores en data centers.
o Existencia de software que permite desplegar, gestionar y monitorizar servidores virtualizados.
- HW genérico, no especializado
o Puede estar distribuido no solo en grandes centros de datos, también en nodos de red o
equipamiento de usuarios finales.
- Funciones tanto del plano de datos como del plano de control.

PROPUESTA DE NFV
- Idea de base: reemplazar los dispositivos físicos de red por software que ofrece la misma funcionalidad,
pero se ejecuta sobre hardware genérico gracias a una capa de virtualización. Los recursos HW
comprenden:
o Procesamiento (CPU + memoria) – computing
o Almacenamiento – storage
o Conectividad – network

13
- Las funciones de red así virtualizadas se llaman VNF: Virtual Network Function.
o Su comportamiento e interfaces externas son idénticos a la función que realizaría el
correspondiente dispositivo físico.
o Idealmente, deben proveerse con interfaces abiertas o bien conocidas para su gestión y
orquestación por parte de terceros. Ej: modelos YANG + NETCONF.
USO DE RECURSOS MÁS FLEXIBLE
NFV proporciona disponibilidad, tolerancia a fallos y escalado con métodos mucho más flexibles:
- Elasticidad: aumentar o disminuir recursos en función de la demanda de manera mucho más rápida.
o Despliegue o finalización de VNFs, provisionado de recursos virtualizados a las MVs.
- Migración: posibilidad de utilizar más recursos o desplegar más instancias donde se necesite de
manera dinámica.
o Migración de MVs o contenedores, reconexión de servicios.
- Todo ello basado en herramientas software ya bien conocidas y utilizadas en la virtualización de
servidores en datacenters (Ej. Openstack, vSphere –de Vmware- o Kubernetes).
- Se disminuye (idealmente se elimina) la necesidad de sobreprovisionamiento.
POSIBILIDAD DE AHORRO DE COSTES
Menor CAPEX:
- Reduce (idealmente elimina) la dependencia de un proveedor concreto → apertura de mercado, que
puede mejorar las ofertas.
- HW genérico ya se genera masivamente y se utiliza por ejemplo en centros de datos
Menor OPEX:
- Herramientas de gestión independientes del proveedor.
o Sin embargo, dependiendo de la experiencia del usuario, puede ser conveniente adquirir
soluciones de pago que den soporte y garanticen integración y pruebas de los componentes.
- Compartición de infraestructura entre NFV y centros de datos.
- Si se aprovecha la elasticidad, posibilidad de menor consumo de espacio y potencia.
- Nuevos modelos de negocio (ej. pay-as-you-grow, pay-as-you-use) para recursos de red.
AUTOMATIZACIÓN Y TIME-TO-MARKET
Introducción de nuevos servicios más rápida.
- Mediante herramientas SW de automatización, sin necesidad de desplegar nuevos dispositivos HW.
- Se puede descomponer el conjunto de funciones que tiene un equipo tradicional en varias VNFs, de
manera parecida a los microservicios, que permite combinarlas y escalarlas de manera independiente.
- Automatización de algunos procesos más rápida (ej. detección de necesidad de más recursos para una
VNF → solicitud de esos recursos → provisión de esos recursos).
- Favorece DevOps en la red, y va de la mano de varias iniciativas open software, lo que permite
adaptarse a cambios e incorporarlos de manera más rápida.

ARQUITECTURA NFV

- Definida por ETSI.

- Permite a varios vendedores coexistir
en el ecosistema
- HW – VNFs – Gestión, con puntos de
intercomunicación bien definidos

14
NFVI (INFRAESTRUCTURA)
Hardware: Capa de virtualización: Conectividad entre máquinas
Puede ser exclusivo para NFV o Puede ser open source (sin coste virtuales, PoPs, … necesaria para la
compartirse con otros servicios y de licencia) o de un vendedor utilización de los recursos HW
aplicaciones en un centro de datos concreto (con soporte). distribuidos:
COTS o de un fabricante concreto. Basada en máquinas virtuales o en Se considera parte de la NFVI. 
Puede incluir switches virtuales y
Previsión de escalado futuro si es contenedores.
físicos
necesario, sin afectar a las VNF Soporte para la migración en
actuales. caliente y para aprovechar la
Localización geográfica de los redundancia del HW en favor de la
PoPs. robustez.
Redundancia de los elementos HW. Actualizaciones, soporte por parte
de la empresa o comunidad y
Vida útil de los dispositivos para corrección de bugs.
minimizar fallos.

VIRTUALIZACIÓN

- HW: procesamiento (CPU+ memoria), almacenamiento y networking.

o No necesariamente está en un mismo POP, puede
estar distribuido.
- Virtualización: ej. basada en hipervisores (para crear
máquinas virtuales; ej. KVM, ESXi) o en contenedores (ej.
Docker).
- El creador de una VNF puede indicar requisitos mínimos o
recomendados para ejecutarla (ej. número de núcleos,
memoria, número de interfaces…).
- Ya hay herramientas de virtualización bien conocidas en
el mundo de los centros de datos, que se pueden adaptar
y utilizar en estos entornos.

MANO – GESTIÓN Y ORQUESTACIÓN

- El despliegue, gestión, configuración y orquestación de los elementos es una parte
fundamental de la arquitectura NFV para lograr obtener beneficio.
o Sin una componente importante de interoperabilidad, programabilidad y
automatización, muchos beneficios se diluyen.

- Dentro de MANO se definen distintos elementos funcionales, porque la gestión de los

distintos niveles tiene particularidades:
o Gestión de la infraestructura: VIM – Virtualised Infrastructure Manager
o Gestión de las VNFs: VNFM – VNF Manager
o Orquestación: NFV Orchestrator

VIM - VIRTUALISED INFRASTRUCTURE MANAGER

- Tiene una visión completa de los recursos HW, incluyendo su estado.

- Gestiona la capa de virtualización (ciclo de vida y escalado de las VMs)
- Gestiona las conexiones entre VMs y VNFs.
- Se pueden tener varios VIMs distribuidos, y un VIM puede gestionar varios
bloques NFVI.

15
VNFM - VNF MANAGER

- Gestiona ciclo de vida y gestión FCAPS de las VNF, o bien directamente, o bien hablándose con el EM,
quien gestionará la VNF mediante métodos propietarios y hará de “puente” con MANO.
o Para el escalado de recursos de una VNF, se puede comunicar con VIM o con el orquestador.
- Puede haber VNFM específicos de un proveedor de VNF, con lo que se puede tener > 1 bloque VNFM.
- No tiene la visión del servicio completo, si este involucra varias VNFs. Para eso está el orquestador.
- El ciclo de vida de una VNF comprende: provisión & instanciado, monitorización, escalado/desescalado
de los recursos, actualización, finalización.
- FCAPS: Fault, Configuration, Accounting, Performance, Security

NFVO - NFV ORCHESTRATOR

- El NFVO tiene la visión del encadenado de VNFs para formar servicios de red, y se comunica con VIM y
con VNFM para provisionarlos.
o Si hay varias VIMs, el orquestador se comunica con todas y tiene la visión global de todos los
recursos que gestionan.
- Puede decidir desplegar más (o finalizar) VNFs para una determinada función si los requisitos de carga o
tráfico así lo aconsejan (elasticidad).
- ETSI define diversos repositorios, catálogos e informes que sirven al orquestador de guía para llevar a
cabo sus funciones relativas a la provisión, gestión y monitorización de los servicios de red.
o Esta información se puede modelar con lenguajes como YANG o TOSCA.
• OSS/BSS: estos sistemas, pueden mantenerse en un escenario que introduzca NFV, migrarse, o
coexistir y comunicarse con el NFVO (ej. a través de una REST API).
• OSS: Operational Support System: Actividades de monitorización, análisis y gestión de red
• BSS: Business Support System: Actividades relacionadas con los clientes
(suscripciones a servicios, facturación, marketing de productos, CRM…)

EJEMPLO DE VIM: OPENSTACK

- Inicialmente es un proyecto que aborda la gestión de clouds: despliegue de VMs y
contenedores + interconexión entre ellos (ej. a través de Open vSwitch).
- Estructura modular (ej. Keystone para autenticación de usuarios, gestión de permisos y comunicación
entre módulos; Neutron para conectividad de red entre VMs; Nova para computación), que incluye un
controlador, puede estar distribuida e incluir redundancia de módulos.
o Soporta migración en caliente de VMs.
- OpenStack puede actuar como VIM en NFV.
- OpenStack es open source.

DISEÑO DE LA RED USANDO VNFS

- El diseño de la red se independiza del despliegue físico del HW.

- Se puede diseñar pensando en funciones y no en dispositivos:
modularización.
o Estas funciones pueden ejecutarse en localizaciones
convenientes de la red, incluso dinámicamente (ej.
para evitar congestión, minimizar retardo, o atender
cambios en la demanda).
- Una posible relación SDN-NFV: el controlador SDN puede ser
una VNF más.

16
QUÉ FUNCIONES VIRTUALIZAR:
- No todas las funciones de red tienen por qué ejecutarse de manera virtualizada. Algunas ofrecerán más
beneficios si se ejecutan en HW.
- Puede haber tanto VNFs como PNFs (Physical Network Functions) para proporcionar un servicio de red.

VNF
- Modelo de negocio: basado en licencias, funcionalidad ofrecida y número de instancias.
o Importante en el diseño tener en cuenta el número de instancias necesarias.
o La migración dinámica en función de la demanda geográfica puede mejorar los costes
- Multi-tenancy: varias VNF con distinta asignación de recursos pueden dar servicio a clientes con
distintos SLA (ej. parámetros de rendimiento).
- VNFs vs CNFs (cloud-native network function): Una CNF sigue una filosofía más cercana al de otros
servicios en la nube. Los despliegues en nube tienden a utilizar contenedores (mientras que las VNFs
inicialmente utilizan más VMs), además de seguir una arquitectura más parecida a una descomposisión
en microservicios.

SERVICIOS DE RED (NS), SERVICE FUNCTION CHAINING

• Un NS es un servicio de red ofrecido a un usuario final, y en general involucra varias Service Functions
(SFs), que pueden ser tanto VNFs como PNF (Physical Network Functions), interconectadas.
• Si las funciones deben intervenir en un orden específico, se establece un SFP (Service Function Path)
o Este mecanismo se denomina SFC (Service Function Chaining)
o Se especifica mediante un VNF-Forwarding-Graph (VNF-FG), que es parte de la información de
la que dispone el orquestador NFV.
• Debe haber un plano de control (Service
Function Controller) que logre el
encaminamiento del tráfico a través de las
funciones de red.
o Una opción es integrarlo con un
controlador SDN, utilizando
protocolos SBI como NETCONF,
RESTCONF u Openflow.

SFC: CLASIFICACIÓN Y REENVÍO ENTRE FUNCIONES

Se define un dominio SFC como una red con una misma administración, a la entrada de la cual se clasifica
el tráfico para ser encaminados a las funciones adecuadas.
• La clasificación puede ser muy flexible (basarse en cabeceras, carga útil, …)
• Se puede añadir una cabecera SFC.
o SFF (SF Forwarder): bloque funcional que, en
función de la cabecera SFC, envía el tráfico a
la siguiente SF, lo recibe de vuelta y repite
para la siguiente función.
o Si hay una SF no preparada para procesar
esta cabecera, se utiliza un proxy hacia dicha
SF.
• Una función puede reclasificar el paquete y desviarlo
hacia otro camino (“branching”).
• En la RFC 8300, IETF define una encapsulación SFC denominada Network Service Header (NSH).

NSH (RFC 8300)

- Contiene información sobre el SFP así como metadatos que codifican información significativa para el
encadenado de las funciones dentro de un dominio.
- Se trata de una señalización “en banda” (se lleva en una de las cabeceras que se incluye en el tráfico de
datos).
- Es procesada por los nodos que implementan el camino (SFs, SFFs, etc.).

17
NFV: CONSIDERACIONES DE COMPLEJIDAD Y RENDIMIENTO
• No es una simplificación, de hecho, desplegar y operar NFV es complejo:
o Muchas capas y abstracciones.
o Interoperabilidad entre productos de distintos fabricantes puede no ser perfecta.
o Diagnóstico de fallos y alta disponibilidad necesita tener en cuenta más variables.
o La securización debe tener en cuenta más capas: equipos en los PoPs, capa de virtualización,
red de transporte, NFVs, sistemas operativos, usuarios que pueden acceder al sistema de
gestión.
• Integración, mantenimiento, verificación y soporte de los productos son fundamentales.
• El rendimiento del software no es igual al del hardware, sobre todo si es HW especializado.
o En NFV, parte del reenvío se hace por software, a través del acceso a NICs virtuales.
o Hay una capa de virtualización intermedia (que también añade sobrecarga) y se utilizan
switches basados en software (ej. OVS).
o Esto es especialmente crítico para las NFV del plano de datos.

RENDIMIENTO SW VS HW
La capacidad de conmutación y reenvío es menor con un vSwitch, lo que puede impactar en el servicio
de red (especialmente si es del plano de datos).
- Algunas opciones para mejorar este aspecto:
• Permitir a ciertas VNFs acceder directa y exclusivamente a las NIC físicas (ej. Ethernet passthrough). Se
pierde flexibilidad.
• SR-IOV (Single Root I/O Virtualization). Es una extensión de la especificación PCIe. Virtualizar las
interfaces físicas “por debajo” del hipervisor, en la propia NIC, aliviando carga de CPU. Para utilizarlo, es
necesario que tanto el hipervisor como las VNF lo soporten.
• DPDK (Data Plane Development Kit): bibliotecas que aceleran el procesamiento de paquetes en
máquinas con HW no especializado. Open source, y principalmente utilizado en Linux.
o OVS-DPDK: OVS con DPDK
o [Link]: basado en DPDK, añade otra optimización en el plano de datos llamada Vector Packet
Processing (VPP)
SOFTWARE DEFINED WIDE AREA NETWORKS ( SD-WAN)

PLANTEAMIENTO DEL PROBLEMA: COMUNICACIONES WAN

• En un entorno de área extendida con sedes geográficamente dispersas, se pueden plantear varias
opciones para la conexión segura entre las sedes, y de estas a Internet, o a nubes públicas y privadas.
o Distintas redes WAN → distinto coste, garantías de QoS o seguridad.
o Los flujos de tráfico utilizarán una u otra tecnología, con posibilidad de cambiar dinámicamente
entre ellas, en función de varios parámetros (ej. en función de la QoS observada a través de
Internet en un momento dado, de los requisitos de las diferentes aplicaciones, y/o la hora)
• Para evitar una complejidad que haga este escenario impracticable, son necesarias herramientas de
gestión y monitorización automatizadas y dinámicas. → SD-WAN
SD-WAN
• Viene a aportar solución al escenario anteriormente planteado mediante tecnologías que incluyen
conceptos de SDN y NFV.
• Se basa en establecer una topología superpuesta (Overlay) sobre las redes WAN concretas (que son las
redes Underlay).
o La topología Overlay se implementa mediante túneles seguros, y no es necesario realizar
cambios sobre las redes “Underlay”.
o Los operadores que proporcionan las redes Underlay pueden ser distintos que el que
proporciona SD-WAN.
o Se pueden establecer múltiples túneles sobre distintos accesos uplink, obteniendo diversidad
de proveedor, de red, o de acceso físico.
o No todos los sites tienen que disponer de las mismas tecnologías “underlay” (ej. puede haber
sites que se conecten a una sola tecnología).
• Hay una gestión y control centralizados de los nodos frontera de las sedes (SD-WAN Edges o CPEs).
• Aunque hay una serie de características comunes, hay diversas soluciones SD-WAN en función del
fabricante / operador

18
TOPOLOGÍAS OVERLAY
Las tres de esta figura son las más habituales, pero esto es muy dinámico e incluso cada aplicación puede
tener una topología distinta.

CARACTERÍSTICAS COMUNES
• Soporte de varias tecnologías WAN: Acceso “cableado” a Internet, acceso WiFi, 4G/5G, acceso a un
servicio de VPN, MPLS, …
• Establecimiento de políticas a nivel de aplicación.
o La definición de aplicaciones puede ser a través de rangos IP, puertos, o incluso a nivel de carga
útil (para lo que puede ser necesario tener DPI - Deep packet inspection).
o Encaminamiento (o re-encaminado dinámico) de las aplicaciones por uno u otro uplink
(utilizando uno u otro túnel) por motivos de:
▪ Fallo del uplink actualmente utilizado.
▪ QoS insuficiente.
▪ Reparto de carga.
▪ Políticas definidas en función de la aplicación (ej. aplicaciones que intercambian
información muy sensible podrían tener prohibido utilizar Internet).
• Seguridad:
o Túneles seguros entre edges.
▪ Gestión de certificados: cada equipo tendrá un certificado que servirá para
autenticación mutua.
o Reglas de firewall (puede haber algunas compartidas para todos los equipos y otras específicas)
o Políticas “Zero trust security”.
• Rápido provisionado de los equipos de frontera:
o Manera segura de “levantar” el equipo Edge y asociarlo al cliente.
o (casi) Zero Touch Provisioning (ZTP): La información de configuración se encuentra previamente
en el sistema de gestión centralizado. Puede requerir introducir un “token” que permita asociar
el equipo al cliente en el backend, o puede venir pre-provisionado con ese “token”.
• Excepciones para acceso a cloud (ej. SaaS bien conocidos) y/o a Internet
o Hay proveedores SD-WAN que disponen de Gateways en PoPs de nubes públicas.
o Internet breakout: parte del tráfico de una sede puede “salir directamente” a Internet sin
utilizar un túnel SD-WAN.
• Monitorización, informes, métricas, analíticas, visualización (dashboards).
• WAN optimization: mejorar la QoS y el ancho de banda percibido mediante técnicas en el plano de
datos como FEC, compresión o caching.

ELEMENTOS DE LA ARQUITECTURA

- SD-WAN Edge, o CPE (Customer Premises Equipment).

o “Frontera” de los sites del cliente.
o SD-WAN Gateway: puede verse como un caso
particular de SD-WAN Edge para conectar con sitios
que utilizan otras tecnologías no gestionadas
mediante SD-WAN.
- Backend: gestión centralizada.
o Controlador + orquestador (en ocasiones combinados)
o Interfaz con el usuario (ej GUI a través de un portal
web) y posiblemente con aplicaciones (ej. REST API).

19
SD-WAN EDGE (O CPE)

- Tiene al menos una interfaz a la red interna de la sede (LAN) y otra a la red extensa (WAN), pudiendo ser
más de uno de cada.
- Funciones:
o Inicio y final de los túneles seguros sobre las WAN.
o Implementa las políticas (policy enforcement) por
aplicación.
o Mide la calidad en cada WAN.
o Puede llevar a cabo parte de la optimización de WAN.
o Puede tener funcionalidades de NAT y firewall.
- Debe comunicarse con el “backend” (controlador) para recibir configuraciones, políticas, enviar
medidas…
- Puede ser un equipo físico o un “virtual appliance”
o En caso de estar virtualizado, puede ejecutarse en un datacenter o en una cloud privada /
pública, o incluso en forma de VNF en un equipo que está físicamente en el sitio del cliente.

BACKEND

- Comunica con:
o Usuarios (portal a través del que se solicitan, activan o modifican servicios) y aplicaciones.
o CPEs o SD-WAN Edges (que son configurados por el backend).
Ambos “extremos” tienen que tener relación (lo que los usuarios soliciten en el portal tiene que
tener su reflejo en la configuración de los CPEs).
- Gestiona:
o Usuarios y permisos.
o Políticas de servicios y aplicaciones.
o Configuraciones de los CPEs, posiblemente permitiendo cambios dinámicos.
o Imágenes SW, actualizaciones (idealmente automatizadas).
o Topología, incluyendo los sites, los tipos de “uplinks” (tecnologías WAN), túneles establecidos ..
o Eventos.
o Métricas
- El backend puede ejecutarse en el cloud, o puede ofrecerse para ejecutarse de manera privada por
parte por ej. de una gran empresa. En cualquier caso, debe estar alcanzable a través de Internet.
- En general, puede ser “multi-tenant” (compartir los recursos del “backend” entre varios clientes a los
que se da servicio).
- Componentes:
o Controlador SD-WAN - interfaz con los SD-WAN Edge: configuración, comunicación de políticas
a aplicar, …
o Orquestador - gestión de los servicios e2e entre los SD-WAN Edge: ciclo de vida del servicio,
rendimiento, seguridad, políticas, …
o Interfaz con el usuario, para permitir:
▪ Dar de alta la cuenta, gestión de usuarios con sus permisos, activación de servicios.
▪ Modificación de políticas de QoS, seguridad o de negocio, que deben reflejarse en los
túneles utilizados por las aplicaciones.

ALGUNOS PRODUCTOS SD-WAN

- Cisco (dos opciones: Viptela y Meraki). Viptela es más flexible para grandes compañías, Meraki es más
fácil de desplegar y más pensado para compañías con equipos de TI reducidos.
- VMware SD-WAN (Velocloud).
- Aruba EdgeConnect SD-WAN.
- SD-WAN segura de Fortinet.
- Colt SD-WAN.

20
TEMA 5: IP MULTIMEDIA SUBSYSTEM

NACIMIENTO Y EVOLUCIÓN DE IMS

ARQUITECTURA
- (2002) 3GPP Release 5 - Nacimiento arquitectura IMS en el contexto de las redes móviles 3G (UMTS).
- (2004) Surgen especificaciones de “Next Generation Networks” para accesos fijos basadas en IMS:
o ITU-T, NGN-FG.
o ETSI, TISPAN, … Colaboraron con 3GPP para una estandarización única y consistente de IMS.
PROTOCOLOS
- IETF: Los protocolos utilizados en IMS son del “mundo Internet”: SIP, RTP/RTCP, DIAMETER DNS, DHCP…
- En el Mobile World Congress 2010 importante repunte de IMS con VoLTE (*), cuyo primer despliegue
comercial se produce en 2012.
- Se ha continuado con la propuesta de usar IMS con otros accesos:
o VoNR: IMS en redes 5G (desde Rel 15 del 3GPP).
o VoWiFi: acceso a IMS desde redes WiFi.

REQUISITOS FUNDAMENTALES DE IMS

• Arquitectura que permite el acceso a servicios multimedia (ej. voz, vídeo) utilizando el núcleo de red IP
del operador.
o Mismo operador ofrece el acceso a los servicios multimedia y los servicios de datos IP.
o Se puede dar una QoS específica a estos servicios multimedia, distinta del tráfico de datos.
• Independencia de la tecnología de acceso (siempre que se proporcione una portadora IP), que puede
ser fija o móvil.
• Soporte de roaming (itinerancia): acceso a los servicios, aunque el usuario esté acampado en una red
visitada (Visited Network) en lugar de en su red matriz (Home Network).
• Soporte de interconexión con otras redes, ej:
o Red telefónica conmutada (PSTN, Public Switched Telephone Network).
o Internet.
• Los servicios ofrecidos pueden evolucionar sin necesidad de ser estandarzados por 3GPP (flexibilidad).

ARQUITECURA DE NIVELES Y ARQUITECTURA BÁSICA IMS

CSCF: CALL SESSION CONTROL

FUNCTION

- En general en una red IMS hay

varios de cada uno de estos
servidores, para escalabilidad y
redundancia.

21
PROXY CALL SESSION CONTROL FUNCTION: P-CSCF
• Primer punto de contacto IMS para los usuarios.
o Realiza compresión/decompresión de los mensajes SIP hacia /desde los UE.
o Mantiene las asociaciones de seguridad (SA – Security Associations) con el UE.
• Actúa como un proxy SIP (outbound + inbound):
o Reenvía las peticiones de registro SIP recibidas de los UE.
o Reenvía los mensajes SIP entre UE servidor SIP (S-CSCF obtenido en el proceso de registro).
• Interacciona con el PCRF (generación de registros de tarificación).
• Reside habitualmente en la red en la que se encuentra el usuario (Home o Visited).

INTERROGATING CALL SESSION CONTROL FUNCTION: I-CSCF

• Proxy SIP situado en la frontera de un dominio administrativo.
o Como tal, su dirección se puede obtener mediante DNS preguntando por ese dominio.
• Actúa interrogando al HSS para determinar el siguiente servidor al que enviar una petición SIP en dos
circunstancias:
o Durante el registro del usuario: para determinar el S-CSCF que le dará servicio.
o Durante el encaminamiento de la señalización inicial de una comunicación entrante a un
usuario del operador (ej. terminating call).
• Reside habitualmente en la red matriz del usuario (Home).

SERVING CALL SESSION CONTROL FUNCTION: S-CSCF

• Punto central de IMS.
o Toda la señalización SIP de/a un terminal pasa por el S-CSCF que se le ha asignado durante el
registro.
• Durante el procedimiento de registro: actúa como SIP Registrar (informa al HSS de que él es el nodo
que da servicio al usuario), descarga del HSS y almacena los perfiles de servicio del usuario (ej. con
servicios permitidos y prohibidos), obtiene del HSS los datos de autenticación y autentica al usuario
(challenge / respuesta).
• Durante todo el tiempo que el usuario está registrado: como SIP proxy (o como User Agent dependiendo
del servicio), supervisa el estado de registro, realiza el control de sesiones, determina el
encaminamiento de la señalización SIP, gestiona la interacción con los AS (a través de los filtros de
“disparo” de servicios, ejecuta el envío de señalización a los ASs adecuados durante la ruta de la
señalización hasta su destino), decide si se realiza “breakout” a una red CS, …
• Reside siempre en la red matriz del usuario (Home).

POLICY AND CHARGING RULES FUNCTION: PCRF

• Comunica con el P-CSCF:
o Toma decisiones de políticas y tarificación basado en información recibida del P-CSCF.
o Recibe informes de eventos en el plano de usuario y se los comunica al P-CSCF.
• Comunica con el GGSN, PDN-GW o UPF (en redes PLMN) (*) para aplicar las reglas (autorizar los flujos,
reglas de charging). (*) nombres que reciben los nodos de plano de datos que se encargan, en
GPRS/HSPA, 4G y 5G respectivamente, de los flujos de datos desde los usuarios de la red hacia redes
externas) para aplicar las reglas (autorizar los flujos, reglas de charging).

HOME SUBSCRIBER SERVER: HSS (+ SLF)

• Principal repositorio de datos de cliente y relativo a los servicios.
• Almacena:
o Identidades de usuario (privada y pública).
o Parámetros de acceso a IMS (ej. información de autenticación).
o Información de disparo de servicios (condiciones que pueden hacer por ej. que el S-CSCF
encamine mensajes SIP a uno o varios AS).
o Cuando el usuario está registrado en IMS, el S-CSCF que le está dando servicio.
• Cada usuario tiene sus datos en el HSS de su Home Network.
• Si hay varios HSS físicos: SLF (Subscription Locator Function) permite determinar cuál es el HSS en que
se encuentran los datos de un abonado concreto.

22
INTERCONEXIÓN CON REDES CS: BGCF, MGCF, MGW, SGW

BREAKOUT GATEWAY CONTROL FUNCTION: BGCF

• Utilizado principalmente en los tránsitos entre una red IMS y una red en el dominio CS (principalmente
PSTN, 3G o 2G).
o Determina el próximo salto para el encaminamiento de un mensaje SIP en escenarios de
llamadas desde IMS hacia una red CS.
• El breakout puede producirse en la red propia o en otra red:
o Si es en la propia red, el BGCF selecciona el MGCF responsable del interfuncionamiento con el
dominio CS.
o Si es en otra red, reenvía la señalización de la sesión al BGCF correspondiente

MEDIA GATEWAY CONTROL FUNCTION: MGCF (+ MGW + SGW)

• Es considerado como un “SIP endpoint”.
• Realiza conversión de protocolos entre SIP e ISUP.
• Encamina las peticiones:
o Desde IMS hacia el dominio CS, y
o desde el dominio CS hasta el I-CSCF.
• El MGW proporciona enlaces de plano de usuario entre CS y IMS.
• El MGW termina los canales portadores y los flujos de media, convierte y realiza el procesamiento de
señal y la transcodificación necesaria.
• El SGW realiza traducción del transporte de señalización (niveles bajos): SCTP/IP MTP.

MEDIA RESOURCE FUNCTION: MRF

• Proporciona servicios de procesado de medios independientes de la aplicación.
• Funciones:
o Mezclado de flujos de media entrantes (ej. para multiconferencia)
o Fuente de flujos de media (ej anuncios)
o Procesamiento de media (ej transcodificación)
o IVRS (Interactive Voice Response System)
• Desde el punto de vista de señalización, se comporta como un agente de usuario SIP.
• Reside en la red matriz del usuario (Home).

APPLICATION SERVER: AS
• Función en la capa de aplicación de IMS que proporciona servicios multimedia de valor añadido.
• Capacidad para procesar e impactar las sesiones entrantes desde la red IMS.
• Capacidad para originar peticiones SIP.
• Capacidad de enviar información de accounting a las funciones de tarificación.
• Ejemplo: TAS (Telephony Application Server), que soporta servicios suplementarios como desvío de
llamadas o restricción selectiva de llamadas (call barring).
• Reside o bien en la red matriz del usuario (Home Network) o bien en un “Third party”.

23
IMS: IDENTIFICACIÓN DE USUARIOS

Identidad privada:
- Cada usuario tiene una o más identidades privadas.
- Es asignada por el operador de red propio (home network operator) y utilizada en procedimientos de
registro, autorización, autenticación etc.
- Puede contener una representación del IMSI (abonados móviles).
Identidad pública:
- Cada usuario tiene una o más identidades públicas.
- Es la identidad usada por otros usuarios para el establecimiento de sesiones.
- Se puede utilizar numeración de redes PSTN (números de teléfono) y esquemas de nombres de Internet
(SIP URIs).

PROCEDIMIENTOS IMS

• Registro en IMS.
• Establecimiento sesiones entre interlocutores IMS:
o Originating IMS Home → Terminating IMS Home.
Llamante y llamado en sus respectivas redes matriz.
o Originating IMS Visited → Terminating IMS Home.
Llamante en itinerancia, llamado en su red matriz.
En todos estos casos se supondrá que
o Originating IMS Visited →Terminating IMS Visited.
el procedimiento de registro de los
Llamante y llamado en itinerancia.
interlocutores en la red se ha realizado
• Interfuncionamiento CS IMS: previamente de manera exitosa.
o Originating CS →Terminating IMS Home.
Llamante PSTN, llamado en su red matriz IMS.
o Originating IMS Home → Terminating CS.
Llamante en su red matriz IMS, llamado PSTN.

REGISTRO

24
REGISTRO: INFORMACIÓN DE ENCAMINAMIENTO

Tras el registro:
• El resto de las peticiones salientes del UE no tendrán que pasar por el I-CSCF antes de llegar al S-CSCF:
o UE → P-CSCF → S-CSCF
• Las peticiones entrantes hacia el UE que lleguenal S-CSCF siempre pasarán previamente por el P-CSCF:
o S-CSCF → P-CSCF → UE
• Esto se logra gracias al uso de diversas cabeceras de encaminamiento en determinadas peticiones y
respuestas de SIP.

25
FLUJO GENERAL DE UN ESTABLECIMIENTO DE SESIÓN

ESTABLECIMIENTO DE SESIONES IMS: ORG IMS HOME → TERM IMS HOME

26
ESTAB. DE SESIONES IMS: ORG IMS VISITED → TERM IMS HOME

ESTAB. DE SESIONES IMS: ORG IMS VISITED  TERM IMS VISITED

LLAMANTE CS → LLAMADO IMS (HOME)

Origination PSTN – Termination Home/Visited PLMN
1. La red PSTN intercambia señalización SS7 con el MGCF (a través de SGW) y establece una conexión
(portador) con el MGW.
2. El MGCF intercambia señalización SIP con los elementos de la red IMS del abonado destino, a través del
I-CSCF.
3. El I-CSCF consulta al HSS para obtener el S-CSCF en el que esa registrado el UE.
4. EL MGCF, mediante comandos H.248, indica al MGW los recursos necesarios para la sesión.
5. EL MGW reserva los recursos necesarios para los flujos de la sesión (VoIP) sobre protocolo RTP.

27
LLAMANTE IMS (HOME) → LLAMADO CS
Origination Home PLMN – Termination PSTN
Este procedimiento se aplica a usuarios origen en su propia red PLMN y destino localizados en una red CS
(PSTN). Secuencia de acciones:
1. El primer INVITE sigue el camino UE → P-CSCF → S-CSCF.
2. El S-CSCF analiza la dirección destino y determina que pertenece a la red PSTN; encamina hacia el
BGCF (CS Breakout).
3. El BGCF encamina la sesión hacia el MGCF (o hacia otro BGCF).
4. El MGCF intercambia señalización SS7 con la red PSTN (a través de SGW).
5. El MGCF, mediante comandos H.248, indica al MGW los recursos necesarios para los flujos de la sesión
multimedia (VoIP).

28