DIAMETER

Diameter es un protocolo diseado para

proveer las funciones de Authentication,
Autorization y Accounting (AAA).
Authentication es:
Proceso por el que una entidad prueba su identidad ante
otra.
Normalmente la primera entidad es un cliente y la
segunda un servidor.
La Autenticacin se consigue mediante la presentacin
de una propuesta de identidad y la demostracin de estar
en posesin de las credenciales que permiten
comprobarla.
Ejemplos de credenciales: contraseas, tokens,
certificados digitales, etc.
Authorization es:
El acto de determinar si la entidad que solicita un
servicio/recurso tiene privilegios para acceder a ste.
Se conceden privilegios especficos a una entidad o usuario
basndose en su identidad, los privilegios que solicita, y el
estado actual del sistema.
Las autorizaciones pueden estar basadas en restricciones,
tales como restricciones horarias, sobre la localizacin de la
entidad solicitante, la prohibicin de realizar logins mltiples
simltaneos del mismo usuario,etc.

Accounting es:
El acto de recoger informacin de la utilizacin de recursos
con el objetivo de planificar la capacidad, auditar, facturar o
asignar coste.
Para proporcionar accounting hay que hacer un seguimiento
del consumo de los recursos de red por los usuarios.
Tpicamente se registra informacin tal como, identidad de
usuario, tipo de servicio, fecha de inicio del uso o fecha fin de
uso, etc.
 Diameter se basa en el protocolo RADIUS.
Curiosidad: el nombre de Diameter proviene de la geometra
(Diameter = 2 x Radius).
Diameter fue estandarizado en Septiembre de 2003 a travs
del RFC3588 donde se establecen las bases del protocolo.
En Octubre de 2012 apareci el RFC6733 que ampla y
actualiza al RFC3588.
Aunque Diameter esta diseado para proveer funciones AAA,
el protocolo base solo desarrolla la aplicacin de Accounting.
El resto de funciones/aplicaciones deben ser definidas a travs
de extensiones.
Diversas aplicaciones Diameter se definen en su propios RFCs
y hay aplicaciones propietarias.
Estructura Lgica de Diameter
Aplicacin Diameter:
Serie de comandos que amplan las capacidades del protocolo
base.
Una aplicacin esta formada por varios comandos.
Cada aplicacin tiene un ID asignado por el IANA.
Ejemplos: Diameter Credit Control, Mobile IPv4, aplicaciones
3GPP como Cx, Gx, etc.
Comandos Diameter:
Define una accin necesaria para poder ejecutar una aplicacin
Diameter.
Cada comando tiene un ID (command code) y dos tipos de
mensajes: Solicitudes o Requests (R) y Respuestas o Answers
(A).
Ejemplos: UAR (User Acceptance Request), UAA (User
Acceptance Answer), etc.
AVP (Attribute-Value Pairs):
Los AVPs encapsulan informacin especfica contenida en el
comando y cada AVP tiene un ID.
Ejemplos: Origin-Host, Destination-Realm, etc.
 El protocolo base especifica lo relativo a:
Formato del mensaje
Transporte
Reporte de Errores
Accounting
Seguridad
Cualquier aplicacin Diameter debe usar el protocolo Base
de Diameter.
El protocolo Diameter ha sido diseado para ser muy
extensible.
Entre sus caractersticas principales:
Definir nuevos valores AVP
Creacin de nuevos AVPs
Crear nuevos comandos
Crear nuevas aplicaciones
Terminologa

Peer. Dos nodos Diameter que comparten una conexin de

transporte se llaman peers.
Nodo. Un nodo es un host que implementa el protocolo
Diameter.
Realm. Es un dominio administrativo con el cual el usuario
mantiene una relacin de suscripcin.
NAI (Network Access Identifier). Es un string que contiene
la identidad del usuario y de su realm.
Ejemplo: alice@example.com.
Tipos de Nodos Diameter
Un nodo Diameter es un host que
implementa
Diameter.
Tenemos tres tipos de nodos:
1 Clientes. Un cliente es un nodo Diameter que soporta
aplicaciones Diameter y tambin, el protocolo base.
Normalmente son objetos situados en el limite de una red que
facilitan servicios de control de acceso a esa red
2 Servidores. Un servidor Diameter proporciona servicios de
authentication, authorization y accounting.
Debe soportar aplicaciones Diameter de servidor adems del
protocolo base.
3 Agentes. Un agente es un nodo Diameter que proporciona
distintas funcionalidades tales como servicios de enrutamiento
(relay y proxy), redireccin (redirect) y traduccin (translation).
Agentes en Diameter
Los agentes son tiles porque:
Pueden ser utilizados para concentrar peticiones y distribuirlas
(evitando tener un nmero de conexiones entre peers de orden
N2).
Pueden distribuir la administracin de sistemas de una forma
mas configurable incluyendo la gestin de la seguridad.
Pueden ser utilizados para balanceos de carga.
Una red compleja puede tener mltiples orgenes de
autenticacin, los agentes pueden ayudar a filtrar solicitudes y
redirigirlas a los nodos correctos.
Tenemos cuatro tipos de agentes: relay, proxy,
redirect
y translation.
Agente Relay
Aceptan peticiones y enrutan los mensajes a otros nodos
Diameter basndose en la informacin que aparece en el
mensaje.
La decisin de enrutamiento se basa en una lista de realms
soportados y peers conocidos.
Esta informacin est en la tabla de enrutamiento
Diameter.
Los relays modifican el mensaje Diameter aadiendo o
eliminando informacin de enrutamiento pero no modifican
ninguna otra informacin del mensaje.
No mantienen informacin del estado de la sesin pero si del
estado de la transaccin (Request/Answer).
Agente Proxy
Al igual que los relays enrutan los mensajes usando una
tabla de enrutamiento Diameter.
A diferencia de los relays modifican los mensajes
Diameter.
Poder modificar mensajes Diameter permite a los proxies
proporcionar servicios de valor aadido en la red
Diameter.
En el intercambio de capacidades, un proxy solo debe
anunciar las aplicaciones que soporta (ya que debe
entenderlas para modificarlas).
Agente Redirect
Envan informacin del peer con el que el nodo que
consulta debe comunicarse.
No modifican mensajes ni mantienen informacin del
estado de la sesin.
Son tiles en escenarios donde la configuracin de
enrutamiento Diameter est centralizada.
Agente de Traduccin
Se encarga de hacer la traduccin entre 2 protocolos.
El caso ms habitual RADIUS<->Diameter.
Mantienen el estado de la sesin y el estado de la transaccin.
La traduccin slo puede ocurrir si el agente es capaz de
identificar la aplicacin de la solicitud.
Los agentes traductores slo deben anunciar como capacidad
las aplicaciones que soportan.
 Formato de Mensajes Diameter

Los mensajes en Diameter estn formados por una

cabecera o
header que ocupa 20 octetos seguido por una cantidad
variable
de AVPs
Los AVPs llevan informacin especifica de
autenticacin,autorizacin, accounting, routing y
configuracin especifica de solicitudes y respuestas.

AVP Code. 4 octetos. Combinado con el campo Vendor-ID

identifica de forma nica el atributo. Los cdigos del 1 al 255
estn reservados para RADIUS. Del 256 en adelante son
utilizados por Diameter. La IANA gestiona estos valores.

AVP Flags. 8 bits. Indican al receptor como debe ser

procesado cada atributo
V. Indica si el campo opcional Vendor-ID esta presente en el AVP o
no.
M. Conocido como bit obligatorio, indica si el receptor del mensaje
debe entender o no la semntica del mensaje. El receptor debe
responder con un mensaje de error en el caso que reciba un AVP
con M =1 y no sea capaz de entenderlo.
P. Reservado para uso futuro (para seguridad end-to-end).
r. Reservado para uso futuro.
 AVP Length. 3 bytes. Nmero de bytes del AVP. Los
mensajes con longitudes errneas debe rechazarse.
Vendor-ID. Opcional. 4 bytes. Contiene el valor
asignado por la IANA al vendor.
Accounting
Los servidores de Accounting generan los accounting
records a travs del procesamiento de eventos que ocurren
en las sesiones.
Existen dos comandos relacionados con Accounting:

Comando Accounting-Request (ACR)

Identificado con el Command Code 271.
Command Flag R=1.
Enviado por el nodo Diameter que acta como cliente
para intercambiar informacin de Accounting.

Comando Accounting-Answer (ACA)

Identificado con el Command Code 271.
Command Flag R=0.
Responde con un ACA el nodo que acta como Servidor.
IMS
EVOLUCIN DE LAS CENTRALES TELEFNICAS

NGN es un servicio de telefona que ofrecen las operadoras y

que consiste en enlazar la empresa con el operador
mediante una conexin de datos (una fibra ptica) para
cursar todas las llamadas entrantes y salientes.
CENTRAL TELEFONICA

ENRUTAMIENT
ACCESO SERVICIOS
O
NGN

Una Red de Siguiente Generacin es una red basada en la transmisin

de paquetes capaz de proveer servicios integrados, incluyendo los
tradicionales telefnicos, y capaz de explotar al mximo el
ancho de banda del canal haciendo uso de las Tecnologas de Calidad
del Servicio (QoS) de modo que el transporte sea totalmente
independiente de la infraestructura de red utilizada. Adems, ofrece
acceso libre para usuarios de diferentes compaas telefnicas y apoya
la movilidad que permite acceso multipunto a los usuarios

Las Redes de Siguiente Generacin estn basadas en tecnologas

Internet incluyendo el protocolo IP y el MPLS. En el nivel de
aplicacin, los protocolos SIP, parecen haberse incorporado desde la
norma ITU-T H.323.
IDENTIDAD en IMS

IP Multimedia Private Identity:

The IP Multimedia Private Identity (IMPI) is a unique permanently
allocated global identity assigned by the home network operator, and is
used, for example, for Registration, Authorization, Administration, and
Accounting purposes. Every IMS user shall have one IMPI.

IMPI = imsi@dominio

716060800333333@ims.volte.movistar.pe
IP Multimedia Public Identity:
The IP Multimedia Public Identity (IMPU) is used by any user for requesting
communications to other users .There can be multiple IMPU per IMPI. The IMPU
can also be shared with another phone, so that both can be reached with the
same identity (for example, a single phone-number for an entire family).

IMPU : tel: +51999192625

sip: 51999192625@ims.volte.movistar.pe
sip: 716060800333333@ims.volte.movistar.pe

Globally Routable User Agent URI:

Globally Routable User Agent URI (GRUU) is an identity that identifies a unique
combination of IMPU and UE instance. There are two types of GRUU: Public-
GRUU (P-GRUU) and Temporary GRUU (T-GRUU).
P-GRUU reveal the IMPU and are very long lived.
T-GRUU do not reveal the IMPU and are valid until the contact is explicitly de-
registered or the current registration expires
 SAP (Session Announcement Protocol).
Protocolo para el anuncio (utilizando broadcast o
multicast) de sesiones multimedia sobre redes IP.
Los parmetros de la sesin se expresan mediante SDP.
Usado principalmente en servicios streaming live como
IPTV.
RTSP (Real-Time Streaming Protocol).
Permite al usuario controlar la reproduccin de un
servicio stored streaming.
Es decir, rewind, FF, pause, resume, etc.
RSVP (Resource Reservation Protocol).
Protocolo para la reserva de recursos de un cierto
camino en la red para proveer de calidad de servicio
(QoS) a los flujos multimedia.
Protocolos IETF Multimedia

Principales protocolos relacionados con multimedia:

RTP (Real-Time Protocol).
Usado para transmisiones a tiempo real e interactivas.
Extiende UDP y se sita entre la aplicacin y UDP.
RTCP (Real-time Control Protocol).
Usado para el intercambio de informacin de control de
un flujo RTP.
SDP (Session Description Protocol).
Define una estructura de datos para describir una sesin
multimedia.
Es decir, describe codecs, bitrate, protocolos de transporte,
puertos, direcciones IP, etc.
SIP (Session Initiation Protocol).
Protocolo para establecer sesiones multimedia de forma dinmica
sobre redes IP.
Los parmetros de la sesin se expresan mediante SDP.
Usado en servicios interactivos como llamadas VoIP
RTP: Real-time Transport Protocol.
Estndar original es el RFC 1889 (Enero 1996).
Actual estndar es el RFC 3550 (Julio de 2003).
Adems se acompaa de otro protocolo de control
denominado RTP Control Protocol (RTCP).
Hubo un dilema en su diseo:
Si implementar RTP como una subcapa de transporte o
en la parte de aplicacin.
Impacto de la decisin: en el kernel (OS) o en espacio
de usuario (aplicacin).
Finalmente, se decidi que RTP se implementa como
una librera de aplicacin.
Ejemplo la JMF: Java Media Framework.
El protocolo TCP no se utiliza en general para la
transmisin de flujos multimedia a tiempo real porque:
No soporta multicast.
Las cabeceras TCP con mayores que las UDP (40
bytes versus 8 bytes).
El control de congestin de TCP decrementa la ventana
cuando se producen prdidas (slow start).
Fuerza al receptor a esperar a retransmisiones en caso
de prdida, lo que tiene como consecuencia grandes
latencias.
TCP no permite prdida de paquetes (los retransmite)
mientras que en un flujo multimedia unas prdidas del
1% al 20% pueden ser tolerables (se pueden
compensar con FEC, entrelazado y PLC).
Por ello, RTP se disea sobre UDP.
 RTP/UDP nos proporciona:
Identificacin del payload (permite implementar
traductores o recodificaciones).
Deteccin de prdidas (nmero de secuencia RTP y
checksum UDP).
Correccin del Jitter (Timestamps y playout adaptativo).
Envos multicast (mediante UDP).
Multiplexado de audio/video streams que pueden
pertenecer a diferentes fuentes (campos SSRC y
CCRC).
Notar que RTP no garantiza una calidad de servicio en
la entrega del flujo real-time (puede haber retrasos,
prdidas, desorden).
 RTCP nos proporciona adicionalmente:
Las fuentes y receptores pueden monitorizar el flujo
RTP y mediante RTCP pueden dar feedback al otro
extremo.
Mediante los parmetros recibidos por RTCP las
aplicaciones pueden aadir ms o menos fiabilidad a
sus flujos, realizar control de congestin, etc.
En conferencias, RTCP permite descubrir a otros
nodos.
RTCP tambin permite la sincronizacin de varios
audio/video streams pertenecientes a diferentes
fuentes de la misma sesin multimedia (mediante
RTCP).
53