6a AAA-Diameter

ARQUITETURA NGN / IMS
AAA: autenticação, autorização, contabilização; interfaces Diameter
Campinas, Fevereiro de 2010.
© Copyright Trópico – Todos os direitos reservados

AAA na Internet
RADIUS (Remote Authentication

Dial In User Service): protocolo
utilizado para AAA na Internet
[RFC2865]
Uso típico:
o PC com modem disca para
um NAS (Network Access
Server) RADIUS funciona bem para configurações de pequeno porte:
o NAS é configurado para RADIUS roda sobre UDP
solicitar autenciação e Não tem controle de congestionamento
autorização para um AAA Dados podem ser perdidos
Server, usando o RADIUS tem deficiências, como:
protocolo RADIUS (tipo Facilidade para que o AAA Server envia mensagens não-
pergunta e resposta) solicitadas ao servidor de acesso.
Um protocolo com melhor desempenho e facilidades é necessário    DIAMETER
© Copyright Trópico – Todos os direitos reservados 2

DIAMETER e IMS

DIAMETER e IMS
Diameter base Protocol RFC 3588 -
Diameter Command for 3GPP RFC 3589 -
AAA Transport Profile RFC 3539 -
Sh interface (3GGP TS 29.328 & TS 29.329) Interface entre HSS e SIP AS / OSA SCS
Dh interface (3GGP TS 29.328 & TS 29.329) Interface SLF e SIP AS / OSA SCS
Rf interface RFC 4006, 3GGP TS 32.225 & TS 32.299 Interface entre CDF e P-CSCF / I-CSCF / S-CSCF / BGCF / MRFC /
MGCF / AS
Ro interface RFC 4006, 3GGP TS 32.225 & TS 32.299 Interface entre OCS e AS / MRFC / S-CSCF
Re interface 3GPP TS 32.296 Interface entre EBCF (Event Base Charging Function) e “Rating
Function” (tarifação online)
Cx interface 3GPP TS 29.228 & TS29.229 Interface entre HSS e I-CSCF / S-CSCF
Dx interface 3GPP TS 29.228 & TS29.229 Interface entre SLF e I-CSCF / S-CSCF
Rx interface 3GPP TS 23.203 & TS 29.214 Interface entre P-CSCF e PCRF
Gx interface 3GPP TS 29.212 & TS 23.203 Interface entre PCRF e Access gateway
Gy interface 3GPP TS 32.299 Interface entre PCEF e OCS
Gz interface 3GPP TS 32.240 Interface entre PCEF e OFCS
Gq interface 3GPP TS 29.209 Interface entre P-CSCF e PDF
[definida no 3GPP release 6, foi alterada para interface Rx atualizada
no 3GPP Release 7, com a introdução do PCRF e encapsulando a
função PDF]
Zh/Dz/Zn interfaces 3GPP TS 29.109 & 3GPP TS 33.220 Interfaces entre HSS e Bootstrap Server Functionality (Zh), SLF e BSF
(Dh), BSF e NAF (Zn)
Gi/Dw/Wa/Wd/Wx/Wg/Pr/Wm/ 3GPP TS 29.234 Interfaces com WLAN:
Wo/Wf interfaces 3GPP AAA Server e PDG, (Gi) 3GPP AAA Server e SLF (Dw), WLAN AN e
3GPP AAA Proxy (Wa), 3GPP AAA Proxy e 3GPP AAA Server (Wd),
3GPP AAA Server e HSS (Wx), 3GPP AAA Server and the PDG (Wm),
3GPP AAA Server/Proxy e WAG (Wg), 3GPP AAA Server e PNA (Pr),
3GPP AAA Server e OCS (Wo), 3GPP AAA Server e CCF (Wf).

DIAMETER
Diameter é um protocolo para

autenticação, autorização e
contabilização, fracamente
baseado no protocolo RADIUS.
O protocolo Diameter é dividido

nas partes:
Protocolo base definido pela

RFC3388: define unidades de
dados, capacitações de
negociação, tratamento de
erros, e extensabilidade.
Aplicações Diameter: define

funções e unidade de dados
Um protocolo base (RFC3588), e extensões para
especificas de uma
diferentes aplicações.
aplicação. Cada
especificação Diameter é
especificada separadamente.

DIAMETER Funcionalidades do protocolo base:
Connection management:
Peer discovery: definição do destinatário da mensagem
(configuração estática, DNS).
Transport: SCTP, TCP (podendo ter segurança IPSec,
TLS).
Capabilities negotiation: troca de mensagens de
capacitação (CER/CEA), criando tabela de estado dos
interlocutores (peers).
Peer liveness and disconection: supervisão para definir
quando a conexão com um interlocutor está em falha.
Routing management:
Tipo de nós: são previstos 3 tipos de nós: clientes
(iniciam uma solicitação), servidores (tratam as
solicitações), e agentes (repassam, redirecionam, ou
transladam as solicitações).
Gerar requests, responder requests, detectar loop,
detectar duplicação de mensagens, reencaminhamento
em caso de falha.
Tabela de roteamento: lista dos encaminhamentos
(domínios).
Session management:
Sessão: seqüência de eventos devotados a uma
Aplicações: particular atividade. Uma sessão é identificada pelo
– Propósito específico: NASREQ, SIP, etc. “Session-Id”.
Tipos de sessão: autorização (para autorização e
– Identificada por um “application Id”
autenticação), contabilização (“accounting”).
• Cada aplicação deve ter um identificador de
aplicação alocado pelo IANA Diameter é um protocolo “peer-to-peer”, uma vez que cada nó
• Usado para roteamento de mensagem pode iniciar uma solicitação. Nas operações mais comuns o
CSCF e AS atuam como clientes, e o HSS como servidor.

Tipos de nós DIAMETER
• Diameter Clients and Severs

– Request and Answer Originators
• Where application normally reside
– Advertises supported applications only
• Diameter Agents
– Request and Answer forwarders
– Adds routing information to the message
– Relay Agents
• Provides basic message forwarding
• Does not inspect content of the message
other than Destination-Host and/or Realm
and AppIds
• Advertises support all applications
– Proxy Agents
• Inspects and possibly modifies contents of the Cada nó Diameter tem uma tabela com a lista dos nós conhecidos (peer), e
request or answer it is forwarding. suas propriedades. Esta tabela pode ser populada dinamicamente (neste caso
– Useful in scenarios such policy tem um tempo de expiração), ou estaticamente. Na RFC3588 é mencionado que
enforcement, admission control, esta tabela tem os dados:
provisioning etc
– Can maintain session state Host identity : contém o “Origin-Host” utilizado em alguns AVPs.
• Examples: Translation agents, RADIUS<- StatusT: contém o estado do “peer host” (devem ser iguais ou
>DIAMETER equivalentes aos definidos na RFC3388)
– Static or Dynamic: especifica se esta entrada é configurada
Re-Direct Agents
estaticamente ou dinamicamente.
• Does not forward messages but notifies the Expiration time: tempo em que uma entrada dinâmica deve ser
previous hop of the new next-hop to use atualizada, ou expirada.
• Advertises support all applications TLS Enabled: se TLS é utilizado na comunicação.

Roteamento e sessão

DIAMETER x RADIUS
Diameter:
• Uses TCP and SCTP for communications
• Can be secured using IPSEC and TLS
• End-to-end security is recommended but not mandatory
• Based on request-answer signal pairs
• In the Diameter network there can be clients, relays, proxies, and redirect and
translation agents.

DIAMETER x RADIUS
Fonte: Cisco

DIAMETER
AVP – Attribute Value Pair
 Version: versão do protocolo (deve ser igual a 1)

 Message length: tamanho da mensagem, incluindo o cabeçalho
 Command Flags:
R: REQ - request (=1 para request, =0 para answer)
P: PXY - proxiable (=1 pode ser repassada, =0 deve ser tratada
localmente)
E: ERR - error (=1 indica que a resposta é uma mensagem de erro)
T: retransmission (=1 indica que a mensagem é possivelmente uma
retransmissão)
 Command-Code: código do commando (0 a 255: reservado para
compatibilidade com RADIUS, 16777214 a 16777215: reservado para uso
experimental) AVP flags: informação sobre como tratar o atributo
 Application-ID: identifica a aplicação. As identificações de aplicações são V: indica que o atributo é "vendor-specific" (identificado pelo campo
registradas no IANA (interface Cx = 16777216, interface Sh = 16777217). opcional "Vendor-ID").
 Hop-by-Hop Identifier: auxilia a identificação de solicitações e respostas, e é M: indica atributo mandatório (se não for reconhecido a mensagem
único numa conexão num dado instante de tempo. deve ser rejeitada).
 End-to-End Identifier: usado para evitar duplicação de mensagem (end-to-end) P: indica necessidade de criptografia para segurança fim-a-fim.

Code Mensagem Nome Referencia Utilizado nas
Value interfaces de
interesse DIAMETER: comandos
0-255 RADIUS - [RAD-IANA] -
compatibility
codes Code Mensagem Nome Referencia Utilizado nas
257 CER / CEA Capabilities-Exchange-Req / [RFC3588] Cx, Dx, Sh, Value interfaces de
Capabilities-Exchange-Answer Dh interesse
[inicialização 283 UAR / UAA User-Authorization-Request / User- [RFC4740] -
da aplicação] Authorization-Answer
284 SAR / SAA Server-Assignment-Request / Server- [RFC4740] -
258 RAR / RAA Re-Auth-Request / Re-Auth- [RFC3588] -
Assignment-Answer
Answer
285 LIR / LIA Location-Info-Request / Location- [RFC4740] -
260 AMR / AMA AA-Mobile-Node-Request / AA- [RFC4004] -
Info-Answer
Mobile-Node-Answer
286 MAR / MAA Multimedia-Auth-Request / [RFC4740] -
262 HAR / HAA Home-Agent-MIP-Request / [RFC4004] - Multimedia-Auth-Answer
Home-Agent-MIP-Answer 287 RTR / RTA Registration-Termination-Request / [RFC4740] -
265 AAR / AAA AA-Request / AA-Answer [RFC4005] - Registration-Termination-Answer
288 PPR / PPA Push-Profile-Request / Push-Profile- [RFC4740] -
268 DER / DEA Diameter-EAP-Request / [RFC4072] - Answer
Diameter-EAP-Answer 300 UAR / UAA User-Authorization-Request / User- 3GPP TS Cx, Dx
271 ACR / ACA Accounting-Request / Accounting- [RFC3588] - Authorization-Answer 29.229
Answer 301 SAR / SAA Server-Assignment-Request / Server- 3GPP TS Cx, Dx
272 CCR / CCA Credit-Control-Request / Credit- [RFC4006] Ro Assignment-Answer 29.229
Control-Answer 302 LIR / LIA Location-Info-Request / Location- 3GPP TS Cx, Dx
Info-Answer 29.229
274 ASR / ASA Abort-Session-Request / Abort- [RFC3588] -
Session-Answer 303 MAR / MAA Multimedia-Auth-Request / 3GPP TS Cx, Dx
Multimedia-Auth-Answer 29.229
275 STR / STA Session-Termination-Request / [RFC3588] - 304 RTR / RTA Registration-Termination-Request / 3GPP TS Cx, Dx
Session-Termination-Answer Registration-Termination-Answer 29.229
280 DWR / DWA Device-Watchdog-Request / [RFC3588] - 305 PPR / PPA Push-Profile-Request / Push-Profile- 3GPP TS Cx, Dx
Device-Watchdog-Answer Answer 29.229
282 DPR / DPA Disconnect-Peer-Request / [RFC3588] - 306 UDR/UDA User-Data-Request/-Answer 3GPP TS Sh, Dh
Disconnect-Peer-Answer 29.329
307 PUR/PUA Profile-Update-Request/-Answer 3GPP TS Sh, Dh
RFC3588: Diameter Base Protocol 29.329
RFC3589: Diameter Command Codes for Third Generation Partnership Project (3GPP) 308 SNR/SNA Subscribe-Notifications-Request/- 3GPP TS Sh, Dh
RFC4004: Diameter Mobile IPv4 Application Answer 29.329
RFC4005: Diameter Network Access Server Application 309 PNR/PNA Push-Notification-Request/-Answer 3GPP TS Sh, Dh
RFC4006: Diameter Credit-Control Application 29.329
RFC4072: Diameter Extensible Authentication Protocol (EAP) Application 310 BIR/BIA Boostrapping-Info-Request/Answer 3GPP TS -
RFC4740: Diameter SIP Application 29.109
Nota: RFC4740 e o 3GPP TS 29.229 definem comandos similares (mesmo nome). 311 MPR/MPA Message-Process-Request/Answer 3GPP TS -
Mas, a aplicação SIP da RFC4740 é mais genérica, para uso em outros cenários 29.140
utilizando SIP. É possível o mapeamento entre os AVPs da RFC3740 e os do TS
29.229.

DIAMETER
AVP: formatos Tratamento de erros:

Basic AVP Data Formats OctetString
Integer32 Erros de protocolo: tratados em cada lance
Integer64 (“hop”), e são identificados pelo bit E=1 numa
Unsigned32 mensagem de resposta, e o tipo de erro é
Unsigned64 incluído no Result-Code AVP.
Float32
Float64 Erros de aplicação: a aplicação gera
Grouped. The AVP length field of an AVP of type mensagem de resposta com Result-Code AVP
Grouped is always a multiple of 4. apropriado.
Common Derived AVP Address
Data Formats Os erros são definidos conforme as classes:
1xxx: informativos (uma ação adicional
Time
é necessária para se completar a
UTF8String solicitação requerida)
DiameterIdentity 2xxx: sucesso
DiameterURI 3xxx: erros de protocolo
Enumerated 4xxx: falhas transitórias (uma nova
IPFilterRule solicitação poderá ser bem sucedida)
QoSFilterRule 5xxx: falhas permanentes (uma nova
Grouped AVP Values The Diameter protocol allows AVP values solicitação do mesmo tipo não deve ser
of type 'Grouped.' This implies that the feita)
Data field is actually a sequence of AVPs.

DIAMETER: descrição ABNF dos comandos
O cabeçalho tem o formato:

Header = "<" Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] [application-id]">"

DIAMETER: serviços do protocolo base
O protocolo base provê dois tipos de serviço para as aplicações:
Autenticação e/ou autorização (authentication / autorization):

• cada aplicação define seus códigos de comando e AVPs para autenticação e autorização, e se utiliza
só uma delas ou combinação delas.
Contabilização (accounting):
• a aplicação de contabilização do protocolo base é partilhada entre as aplicações, e somente os AVPs
de contabilização são específicos da aplicação.
• Um comando ACR bem sucedido ativa a contabilização.
• Os registros (“accounting records”) caem em duas categorias:

• Serviços mensurados por duração: que tem inicio e fim claramente definidos, podendo ter
registros intermediários;
• Serviços mensurados por evento: um único registro é produzido.

DIAMETER: fluxo básico de mensagens
A comunicação entre duas entidades Diameter se inicia

com o estabelecimento da conexão de transporte (TCP ou
SCTP).
O originador envia a mensagem CER (Capabilities-

Exchange-Request) para o outra entidade.
Após isto, uma conexão TLS pode ser negociada.
Conexão está pronta para a troca de mensagens

referente a aplicação desejada.
Se nenhuma mensagem for trocada por algum tempo,

qualquer dos lados gera a mensagem DWR (Device-
Watchdog-Request) e o outro lado responde com DWA
(Device-Watchdog-Answer).
Cada lado pode terminar a comunicação enviando DPR

(Disconnect-Peer-Request), que deve ser respondida com
DPA (Disconnect-Peer-Answer).
Após isto, a conexão de transporte pode ser

desconectada.

Interfaces com HSS/UPSF e SLF
A interface entre os CSCF (controladores de sessão de forma geral) e o HSS é a interface Cx. Entre o
CSCF e o SLF é a interface Dx.
A interface entre os AS (servidores de aplicação) e o HSS é a interface Sh. Entre os AS e o SLF é a

interface Dh.
 O MS Forum tem um “Implementation Agreement” para estas interfaces (DB0 é o perfil para as interfaces
Cx e Dx, DB2 é o perfil para as interfaces Sh e Dh), com recomendações a serem seguidas pelas
implementações compatíveis.

Interfaces Cx e Dx
Transporte
Deve ser suportado transporte SCTP, com suporte à fragmentação de pacotes IP. TCP é opcional.
Suporte de IPSec é considerado mandatório para todos os nós Diameter. TLS é opcional.
Roteamento
Na comunicação entre I-CSCF ou S-CSCF e HSS:
• se o endereço do HSS é conhecido, os AVPs Destination-Realm e Destination-Host devem estar
presentes na mensagem;
• caso contrário, somente o AVP Destination-Realm deve estar presente, e a mensagem é encaminhada
para o próximo nó Diameter, um SLF (usando tabela de encaminhamento no cliente).
• Na resposta do SLF deve estar contido o endereço do HSS (Redirect-Host AVP), que será
utilizada para enviar a mensagem ao HSS (o endereço do HSS passa a ser conhecido, e deve
ficar armazenado no I-CSCF ou S-CSCF).
• Para obter o endereço de um HSS, o I-CSCF ou S-CSCF envia ao SLF o comando que ele quer enviar
ao HSS.
Na comunicação entre o HSS e S-CSCF:

• os AVPs Destination-Realm e Destination-Host devem ser incluídos na mensagem.
• o endereço do S-CSCF foi obtido pelo HSS quando o S-CSCF se comunicou com ele anteriormente
(Origination-Host AVP).

DIAMETER: Cx

DIAMETER: Cx

Interfaces Cx e Dx: procedimentos
Identificação da aplicação na interface Cx (Advertising Application Support):
• No estabelecimento da sessão Diameter entre dois nós, uma vez estabelecida a conexão de transporte,
deve ser enviado o comando CER (Capabilities Exchange Request) para estabelecer quais aplicações
Diameter serão suportadas na sessão (aplicação Cx), com os códigos “vendor” do 3GPP e ETSI (ver ETSI TS
183 033, Global modifications to 3GPP TS 29.229, tópico 5.6).
• Uma vez recebido a resposta CEA, as capacitações divulgadas são armazenadas nos dados daquele
servidor Diameter (protocol version number, supported Diameter applications, security mechanisms, etc.).
• Se a conexão de transporte está “em serviço” e as capacitações foram obtidas, a sessão com o servidor
Diameter é considerada “estabelecida”.
• Se for recebido o comando CER de uma fonte conhecida, deve retornar a resposta CEA com seus dados.
• CER recebido de fonte desconhecida deve ser descartado, e a conexão de transporte deve ser fechada
(verificar se existirá alguma aplicação em que deva ser aceito um CER de fonte desconhecida).
• Estes procedimentos se aplicam a qualquer elemento que utiliza a interface Diameter, e os destinos com os
quais ele se comunica.

Gerenciamento de localização: registro e desregistro
• Quando o I-CSCF recebe a mensagem REGISTER de um P-CSCF:

• Envia o comando UAR para o HSS. O HSS responde com UAA, informando o nome do S-CSCF (se existe
um S-CSCF associado ao terminal) ou a capacitação desejada para o S-CSCF (se não existe um S-CSCF
associado ao terminal).
• Se for retornada capacitação:
• A resposta UAA terá o AVP Server-Capabilities, contendo os AVPs: Mandatory-Capability (um inteiro
de 32 bits), Optional-Capability (um inteiro de 32 bits), Server-Name (URI para um SIP server). Cada um
destes AVP pode estar presente ou ausente, e pode ser repetido na mensagem.
• Cada valor incluído nos AVPs Mandatory-Capability e Optional-Capability, representa uma capacitação
do S-CSCF. A especificação deixa a cargo do Operador da rede definir que capacitações são estas e o
mapeamento com estes índices.
• o I-CSCF deve selecionar um S-CSCF baseado em uma lista de S-CSCF que ele deve ter
configurado, com base nos dados de capacitação recebidos.
• se não for recebido nenhum dado de capacitação, nem um nome de servidor, e não for retornado
erro do HSS, será selecionado qualquer S-CSCF da rede (verificar se é a melhor estratégia!).
• Se vários S-CSCF puderem ser utilizados, o I-CSCF pode aplicar algum algoritmo de distribuição de
tráfego.
• Utilizando Server-Name, o Operador pode dedicar um servidor a um grupo específico de usuários.
• O I-CSCF resolve o endereço do S-CSCF e envia a mensagem REGISTER para o S-CSCF.

Gerenciamento de localização: registro e desregistro
• Quando o S-CSCF recebe a mensagem REGISTER do I-CSCF:

• Pré-condição para aceitar o registro é que o terminal tenha tido autenticação bem-sucedida pelo S-CSCF.
• Se o usuário não está autenticado:
• o S-CSCF envia comando MAR ao HSS, para obter dados de autenticação. O HSS responde com
MAA.
• o S-CSCF rejeita o registro enviando resposta de erro 401 Unauthorized para o I-CSCF, e inclui dados
para a autenticação. O S-CSCF guarda as informações de autenticação.
• o terminal do usuário deve enviar nova mensagem REGISTER contendo as informações de
autenticação. O S-CSCF valida os dados, e se aceito, procede com o registro do terminal. Se a
autenticação falha, o registro é rejeitado novamente.
•Se o usuário está autenticado, o S-CSCF envia comando SAR ao HSS, informando que o S-CSCF irá
controlar aquele terminal (se “expires” for diferente de zero), ou que o S-CSCF deixa de controlar aquele
terminal (se “expires” for zero). O HSS responde com SAA contendo dados do perfil do usuário.
• A arquitetura NGN do ETSI prevê a utilização da autenticação HTTP Digest (ETSI TS 183 033, Annex ZA).
• Se, pelo gerenciamento de usuário, a rede decide suprimir o registro de um usuário:

• Por exemplo, quando um terminal foi roubado, ou a subscrição foi cancelada;
• O HSS inicia o desregistro, enviando comando RTR ao S-CSCF;
• O S-CSCF suprime os dados do usuário, e responde com RTA.

Gerenciamento de localização: busca da localização do S-CSCF
• Quando o I-CSCF recebe uma solicitação SIP diferente de REGISTER, o I-CSCF envia comando LIR ao
HSS. O HSS responde com LIA, e informa o nome do S-CSCF (SIP URI) ou as capacitações de um S-CSCF.
• O I-CSCF encaminha a solicitação ao S-CSCF:

• Se o S-CSCF precisar autenticar a solicitação do usuário, ele rejeita a solicitação com o erro 401
Unauthorized, e passa dados de autenticação. O terminal do usuário deve reenviar a solicitação com os
dados de autenticação (e passar novamente pelo encaminhamento do I-CSCF). O S-CSCF deve ter os
dados de autenticação armazenados, desde quando o terminal se registrou.
• Se os dados de autenticação e autorização não forem mais válidos o S-CSCF precisaria se comunicar
com o HSS usando o comando MAR, e resposta MAA, e rejeitar a solicitação passando os dados de
autenticação ao terminal.
Atualização de dados de usuário (download and handle changes in the user data stored in the server)
• Pode ocorrer alteração nos dados de um usuário pelo gerenciamento, e este usuário estar registrado em um
determinado S-CSCF.
• Neste caso o HSS envia o comando PPR ao S-CSCF, que responde com PPA, e atualiza os dados do
usuário que está registrado nele.
• Se o usuário não está registrado, o HSS atualiza seus dados, mas não envia PPR para nenhum S-CSCF.

Interfaces Cx e Dx: mensagens
Utilização UAR UAA SAR SAA LIR LIA MAR MAA RTR RTA PPR PPA CER CEA
Interface entre S-CSCF e x x x x x x x x x x
HSS (Cx)
Interface entre I-CSCF e x x x x x x
HSS (Cx)
Interface entre S-CSCF e x x x x
SLF (Dx)
Interface entre I-CSCF e x x x x
SLF (Dx)
Somente mensagens “request” são enviadas ao SLS, que por sua vez insere o endereço do HSS no cabeçalho da mensagem
Diameter, e a devolve à origem, que poderá roteá-la para o HSS adequado.
São utilizados os comandos Diameter definidos no protocolo base:

CER/CEA – para estabelecer quais aplicações Diameter são suportadas, na inicialização das interfaces Diameter entre os equipamentos.
São utilizados os comandos Diameter definidos para a interface Cx e Dx:

UAR/UAA – determinar se o usuário está autorizado a receber certo serviço, e se autorizado, indica o servidor local capaz de prover este serviço.
SAR/SAA – alocar um SIP Server especifico para um particular usuário, e disponibilizar o perfil do usuário de forma sincronizada.
LIR/LIA – determinar a próxima entidade SIP a ser contactada num proxy de borda.
MAR/MAA – autenticar e autorizar determinado usuário para um serviço SIP especifico (ex: SIP registration). Autenticação pode ser feita no servidor
Diameter ou delegada para um SIP server.
RTR/RTA – desregistro iniciado pelo servidor Diameter (HSS por exemplo).
PPR/PPA – servidor Diameter indica alteração do perfil do usuário, de forma assíncrona.

Interfaces Cx e Dx: AVPs
r = requerido, o = opcional, - = não contém).



Toda resposta deve conter o Result-Code AVP ou o Experimental-result AVP.
Na TS 29.229 são definidos códigos de resultado próprios, que, quando utilizados, devem ser incluídos no AVP Experimental-
result (e o Result-Code AVP deve ser ausente).




Interfaces Cx e Dx: exemplo UAR

Interfaces Cx e Dx: exemplo UAA

Interfaces Cx e Dx: exemplo MAR

Interfaces Cx e Dx: exemplo MAA

Interfaces Sh e Dh
Transporte
Deve ser suportado transporte SCTP, com suporte à fragmentação de pacotes IP. TCP é opcional.
Roteamento
Na comunicação entre AS e HSS:
• se o endereço do HSS é conhecido, os AVPs Destination-Realm e Destination-Host devem estar
presentes na mensagem;
• caso contrário, somente o AVP Destination-Realm deve estar presente, e a mensagem é encaminhada
para o próximo nó Diameter, um SLF (usando tabela de encaminhamento no cliente). Na resposta do
SLF deve estar contido o endereço do HSS (Redirect-Host AVP), que será utilizada para enviar a
mensagem ao HSS (o endereço do HSS passa a ser conhecido, e deve ficar armazenado no AS).
• Para obter o endereço de um HSS, o AS envia ao SLF o comando que ele quer enviar ao HSS.
Na comunicação entre o HSS e AS:

• os AVPs Destination-Realm e Destination-Host devem ser incluídos na mensagem.
• o endereço do AS foi obtido pelo HSS quando o AS se comunicou com ele anteriormente (Origination-
Host AVP).
Interface Dh
Se o AS precisa enviar um comando ao HSS, mas não conhece o endereço, ele envia o comando ao SLF, que
identifica o HSS que deve ser contactado, insere o endereço do HSS no cabeçalho da mensagem, e retorna
esta mensagem ao AS. O AS pode então reencaminhar a mensagem para o HSS adequado.

Interfaces Sh e Dh: procedimentos
Identificação da aplicação na interface Sh (Advertising Application Support)
• No estabelecimento da sessão Diameter entre dois nós, uma vez estabelecida a conexão de transporte, deve
ser enviado o comando CER (Capabilities Exchange Request) para estabelecer quais aplicações Diameter
serão suportadas na sessão (aplicação Sh), com os códigos “vendor” do 3GPP e ETSI (ver ETSI TS 183 033,
Global modifications to 3GPP TS 29.229, tópico 5.6). Uma vez recebido a resposta CEA, as capacitações
divulgadas são armazenadas nos dados daquele servidor Diameter (protocol version number, supported
Diameter applications, security mechanisms, etc.).

Interfaces Sh e Dh: procedimentos
Manipulação de dados
•O HSS guarda dados de usuário que podem ser utilizados pelos AS.
• Estes dados podem ser dados de serviços transparentes (dados utilizados e conhecidos apenas pelo
AS) e não-transparentes, informações de registro, identificações, filtros, nome do S-CSCF que serve o
usuário, endereços de funções de bilhetagem, e também informação de localização tantop no domínio da
rede de circuítos (CS-Domain) ou de pacotes (OS-Domain).
• Dois tipos de operação são possíveis:

•Um AS buscar dados de um usuário armazenados no HSS: AS envia comando UDR e recebe a resposta
UDA.
•Um AS atualizar dados do usuário no HSS, dados transparentes que são de utilização apenas da
aplicação: o AS envia comando PPR com os dados a serem atualizados (dados transparentes), e recebe
a confirmação na resposta PPA.
Subscrição e notificação de alteração de dados
• Um AS pode se subscrever no HSS, para ser notificado quando os dados de um determinado usuário forem
alterados. O AS envia o comando SNR ao HSS, e recebe a resposta SNA, confirmando a subscrição (indicando
o resultado desta operação).
• Quando o HSS reconhece que ocorreu alteração nos dados de um usuário que tem uma subscrição ativa, ele
envia comando PNR ao AS, dando detalhes dos dados alterados. O AS responde com PNA (indicando o
resultado desta operação).
Interfaces Sh e Dh: mensagens
Utilização UDR UDA PUR PUA SNR SNA PNR PNA CER CEA
Interface entre AS e HSS (Sh) x x x x x x x x x x
Interface entre AS e SLF (Dh) x x x x x
Somente mensagens “request” são enviadas ao SLS, que por sua vez insere o endereço do HSS no
cabeçalho da mensagem Diameter, e a devolve à origem, que poderá roteá-la para o HSS adequado.

CER/CEA – para estabelecer quais aplicações Diameter são suportadas, na inicialização das interfaces Diameter entre os
equipamentos.
São utilizados os comandos Diameter definidos para a interface Sh e Dh:

UDR/UDA – para obter dados de um usuário.
PUR/PUA – para atualizar dados de um usuário no servidor.
SNR/SNA – solicitar notificação em caso de alteração de dados de usuário.
PNR/PNA – para notificar alterações de dados de usuário no servidor.

Interfaces Sh e Dh: AVPs


As definições das AVPs definidas para a interface Sh são dadas na tabela. Outras AVPs já foram definidas para na interface Cx.
Toda resposta deve conter o Result-Code AVP ou o Experimental-result AVP.

Na TS 29.329 são definidos códigos de resultado próprios, que, quando utilizados, devem ser incluídos no AVP Experimental-
result (e o Result-Code AVP deve ser ausente).

Tarifação no IMS
Tanto a tarifação “online” quanto a

tarifação “offline” podem ser
categorizados em duas classes
distintas:
“Session-based charging”: usado
quando é necessário manter a sessão
durante todo o serviço. São utilizadas
basicamente as solicitações para o
sistema de tarifação:
“Initial request” (sinaliza o
inicio da tarifação, com dados
da sessão).
“Intermediary request” (pode
ser usado para atualizar dados
da sessão).
“Final request” (usado para
fechar a sessão).
“Event-based charging”: usado para
sinalizar tarifação por evento.
O endereço das entidades de

tarifação pode ser atribuído por
configuração, e, no caso da
sinalização SIP, nas mensagens SIP
no cabeçalho “P-Charging-
Addresses”. A informação de
correlação para tarifação é codificada
no cabeçalho SIP “P-Charging-Vector“
(com os parâmetros ICID, access
network charging identifier e IOI).

Interface Rf
Transporte
Devem ser disponibilizados transporte SCTP e TCP, com suporte à fragmentação de pacotes IP. O port padrão
(3868) deve ser suportado (o receptor deve estar apto a ouvir neste port).
Roteamento
Na comunicação entre o CTF e o CDF o AVP Destination-Realm deve estar presente nas mensagens, com
valor configurado localmente.

Interface Rf: procedimentos
Identificação da aplicação na interface Rf (Advertising Application Support)
• No estabelecimento da sessão Diameter entre dois nós, uma vez estabelecida a conexão de transporte, deve
ser enviado o comando CER (Capabilities Exchange Request) para estabelecer quais aplicações Diameter
serão suportadas na sessão (Diameter base protocol accounting). Uma vez recebido a resposta CEA, as
capacitações divulgadas são armazenadas nos dados daquele servidor Diameter (protocol version number,
supported Diameter applications, security mechanisms, etc.).

Informação para controle da tarifação “offline”
• Para tarifação “offline” são especificadas as mensagens seguintes entre o CTF e CCF:
• Accounting Request (ACR)
• Accounting Answer (ACA)
• Para tarifação por sessão, a AVP “Accounting-Record-Type” pode ter um dos valores:
• START_RECORD – usado para iniciar uma sessão de tarifação (típicamente enviada quando ocorre o
atendimento);
• INTERIM_RECORD – usado para atualizar uma sessão;
• STOP_RECORD – usado para encerrar uma sessão de tarifação (por exemplo, quando a aplicação é
liberada).

Tratamento de falhas
• As aplicações devem examinar as respostas de erro do CCF (AVP Result-Code) na mensagem ACA para
detectar a causa da falha e tomar a ação apropriada.
• Erros gerados internamente, como “unavailable peer” ou “invalid route specification” devem gerar registro de
falha indicando a natureza da falha.
• No caso de falha de comunicação com o CDF:
• Quando a conexão com o CDF primário é interrompida, o processo de envio das informações de
tarifação deve continuar com o CDF secundário (se estiver configurado).
• Se nenhum CDF está disponível, o elemento de rede pode armazenar os dados de tarifação em
memória não-volátil, e uma restabelecida a comunicação com o CDF, todas as mensagens armazenadas
são enviadas ao CDF, na ordem em que foram armazenadas.
• Quando a aplicação envia uma mensagem ACR, uma temporização é utilizada para determinar falha de
resposta do CCF (valor configurável). Ao se expirar a temporização sem resposta ACA:
• A mensagem ACR deve ser repetida, até um número de vezes configurável (ACR retransmitidas são
marcadas com o “T-flag” como descrito na RFC 3588);
• Se nenhuma resposta é recebida, a sessão é encerrada, e o processo de falha de comunicação com o
CDF deve ser seguido;
• Se a resposta ACA for recebida após a temporização expirar e o número de retransmissões ter se
esgotado, ela é descartada.
• Se o CDF abriu uma sessão de tarifação, e não recebe o ACR indicando o fim da sessão após um valor de
temporização configurável, ele fecha o CDR desta sessão.

Interface Rf: mensagens

CER/CEA – para estabelecer quais aplicações Diameter são suportadas, na inicialização das interfaces Diameter entre os
equipamentos.
São utilizados os comandos Diameter definidos para a interface Rf:

ACR/ACA – para envio de informação de tarifação do serviço solicitado.

Interface Rf: AVPs

Interface Rf: AVPs

Interface Rf: AVPs
• Toda resposta deve conter o Result-Code AVP.
• O 3GPP definiu vários AVPs adicionais que se aplicam tanto para tarifação “offline” (mensagens ACR/ACA) quanto
para tarifação “online” (mensagens CCR/CCA), a menos que seja explicitamente excluída. Definições detalhadas
estão na TS 32.299.
• “3GPP Charging Application” usa o valor 10415 (3GPP) como “Vendor-Id”.
• Quando 3GPP RADIUS VSAs são reutilizadas, elas são transladadas para AVPs Diameter como descrito na
RFC4005, com exceção de que o flag “M” deve ser setado, e o flag “P” pode ser setado.

Interface Ro
Transporte
Devem ser disponibilizados transporte SCTP e TCP, com suporte à fragmentação de pacotes IP. O port padrão (3868) deve ser
suportado (o receptor deve estar apto a ouvir neste port).
Roteamento
Na comunicação entre o CTF e o CDF, o AVP Destination-Realm deve estar presente nas mensagens, com valor configurado
localmente.

Interface Ro: procedimentos
Identificação da aplicação na interface Ro (Advertising Application Support)
• No estabelecimento da sessão Diameter entre dois nós, uma vez estabelecida a conexão de transporte, deve ser enviado o
comando CER (Capabilities Exchange Request) para estabelecer quais aplicações Diameter serão suportadas na sessão
(Diameter Credit Control - aplicação interface Ro). Uma vez recebido a resposta CEA, as capacitações divulgadas são
armazenadas nos dados daquele servidor Diameter (protocol version number, supported Diameter applications, security
mechanisms, etc.).
• Se a conexão de transporte está “em serviço” e as capacitações foram obtidas, a sessão com o servidor Diameter é considerada
“estabelecida”.
• CER recebido de fonte desconhecida deve ser descartado, e a conexão de transporte deve ser fechada (verificar se existirá
alguma aplicação em que deva ser aceito um CER de fonte desconhecida).
• Estes procedimentos se aplicam a qualquer elemento que utiliza a interface Diameter, e os destinos com os quais ele se
comunica.

Controle da tarifação “online”
• O objetivo da tarifação “online” é fornecer informação de tarifação ao OCF para controle de créditos antes que
os recursos da rede possam ser utilizados. Desta forma, a conta do usuário pré-pago deve existir no OCF, que
define o custo da utilização dos recursos a serem tarifados.
• Dois casos são definidos (RFC4006):

• Credit authorization with direct debiting – unidades de crédito são imediatamente deduzidas da conta do
usuário numa única transação;
• Credit authorization with unit reservation – unidades de crédito são reservadas pelo OCF, e após o
término do serviço a quantidade utilizada é deduzida da conta do usuário. Unidades reservadas e não
utilizadas são retornadas para a conta do usuário.
• Desta forma três cenários são identificados com respeito ao OCF:

• Immediate Event Charging (IEC) (tipo Event-based charging);
• Event Charging with Unit Reservation (ECUR) (tipo Event-based charging);
• Session Charging with Unit Reservation (SCUR) (tipo Session-based charging):
• Requerida quando é necessário reservar créditos antes de prover o serviço;
• Requer manutenção de estado da sessão de tarifação no OCF;
• OCF inicialmente Multiplas mensagens CCR/CCA podem ser trocadas numa sessão;
• OCF inicialmente reserva o crédito reserva o crédito, e o debita quando receber CCR subsequente.

Para a tarifação “online” são especificadas as mensagens seguintes entre o CTF (cliente) e OCF (servidor):
Credit Control Request (CCR): enviada pelo cliente ao servidor, solicitando autorização para um dado serviço;
Credit Control Answer (CCA): enviada do servidor para o cliente com o resultado da solicitação de autorização;
Reauthorization Request (RAR): enviada pelo servidor para provocar nova CCR (por exemplo, após uma
recarga bem-sucedida durante o serviço);
Reauthorization Answer (RAA): resposta ao RAR.

O AVP “CC-Request-Type” é utilizado para identificar o tipo de solicitação, e deve estar presente em todas as
mensagens CCR, e pode ter os valores:
• INITIAL_REQUEST – usado para iniciar a sessão de tarifação. Para aplicação SIP, os métodos que
disparariam a solicitação são: INVITE (SCUR), NOTIFY (ECUR), MESSAGE (ECUR), REGISTER (ECUR),
SUBSCRIBE (ECUR), REFER (ECUR), and PUBLISH (ECUR);
• UPDATE REQUEST – usado para atualizar informações de uma sessão existente;
• TERMINATION REQUEST – usado para encerrar uma sessão. Para SIP na aplicação, quando for recebida
resposta final (4xx, 5xx, 6xx), sessão for abortada e encerrada (SIP BYE);
• EVENT REQUEST – usado quando não for necessário manter uma sessão de tarifação.
• A AVP “Requested-Action” indica o tipo de ação solicitada, com os valores possíveis:
DIRECT_DEBITING, REFUND_ACCOUNT, CHECK_BALANCE e PRICE_ENQUIRY.


Tratamento de falhas
• As aplicações devem examinar as respostas de erro do OCF (AVP Result-Code) na mensagem CCA para
detectar a causa da falha e tomar a ação apropriada.
• Erros gerados internamente, como “unavailable peer” ou “invalid route specification” devem gerar registro de
falha indicando a natureza da falha.
• Quando a aplicação envia uma mensagem CCR, uma temporização é utilizada para determinar falha de
resposta do OCF (valor default de 10 segundos, mas deve ser configurável). Ao se expirar a temporização sem
resposta CCA:
• A sessão de controle de crédito é encerrada.
• Se a resposta CCA for recebida após a temporização expirar, ela é descartada.
• A aplicação pode tomar ação conforme o valor do AVP “Credit-Control-Failure-Handling”, ou “Direct-Debiting-
Failure-Handling”, incluída na resposta CCA da solicitação CCR ou configurado localmente (ver seção “5.7
Failure Procedures” da RFC4006 para mais detalhes).

Interface Ro: mensagens
• CER/CEA – estabelecer quais aplicações Diameter são suportadas, na inicialização das interfaces Diameter
entre os equipamentos.
• RTR/RTA - provocar nova requisição de créditos para atualização de valores.
• DWR/DWA – como um “ping”, quando não houver atividade.
• DPR/DPA – indica intenção de encerrar a sessão.
• SR/ASA - solicitar que a conexão seja encerrada.
São utilizados os comandos Diameter definidos para a interface Ro:
• CCR/CCA – solicitar créditos.

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs

Interface Ro: AVPs
• Toda resposta deve conter o Result-Code AVP.
• O 3GPP definiu AVPs adicionais que se aplicam tanto para tarifação “offline” (mensagens ACR/ACA) quanto
para tarifação “online” (mensagens CCR/CCA), a menos que seja explicitamente excluída. Definições
detalhadas estão na TS 32.299.
• A “3GPP Charging Application” usa o valor 10415 (3GPP) como “Vendor-Id”.
• Quando 3GPP RADIUS VSAs são reutilizadas, elas são transladadas para AVPs Diameter como
descrito na RFC4005, com exceção de que o flag “M” deve ser setado e o flag “P” pode ser setado.
• Quais são os AVPs incluídos nas mensagens depende de quem está gerando e para qual serviço.

Exemplo ACR (não-IMS)

Campinas Rodovia SP-340, km 118,5
Brasil Pólis de Tecnologia do CPqD – Prédio 12
13086-902 Campinas – SP
Tel.: +55 19 3707-3495
Manaus Av. Abiurana, 449 – Bloco 1

Brasil Distrito Industrial
69075-010 Manaus - AM
Tel.: +55 92 3616-9201
Bogotá Carrera 7 Número 74-56, Oficina 805

Colômbia Bogotá
Tel.: +57 1 313-1725
www.tropiconet.com
Nome Sobrenome
nome.sobrenome@tropiconet.com
Tel.: +55 xx xxxx.mcdu
CONFIDENCIAL – Este documento contém informações confidenciais, de acesso restrito e de titularidade ou posse da
Trópico Telecomunicações da Amazônia Ltda., ou de qualquer de suas controladas ou coligadas, e são protegidas pela
legislação aplicável contra revelação. A posse, visualização, revelação, distribuição ou uso não autorizado(a) deste
documento é estritamente proibido(a).

6a AAA-Diameter

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

6a AAA-Diameter

Enviado por

Direitos autorais:

Formatos disponíveis

ARQUITETURA NGN / IMS

AAA: autenticação, autorização, contabilização; interfaces Diameter

Campinas, Fevereiro de 2010.

© Copyright Trópico – Todos os direitos reservados

RADIUS (Remote Authentication

Um protocolo com melhor desempenho e facilidades é necessário    DIAMETER

© Copyright Trópico – Todos os direitos reservados 2

© Copyright Trópico – Todos os direitos reservados 3

© Copyright Trópico – Todos os direitos reservados 4

Diameter é um protocolo para

O protocolo Diameter é dividido

Protocolo base definido pela

Aplicações Diameter: define

© Copyright Trópico – Todos os direitos reservados 5

© Copyright Trópico – Todos os direitos reservados 6

• Diameter Clients and Severs

© Copyright Trópico – Todos os direitos reservados 7

© Copyright Trópico – Todos os direitos reservados 8

© Copyright Trópico – Todos os direitos reservados 9

© Copyright Trópico – Todos os direitos reservados 10

AVP – Attribute Value Pair

 Version: versão do protocolo (deve ser igual a 1)

© Copyright Trópico – Todos os direitos reservados 11

© Copyright Trópico – Todos os direitos reservados 12

AVP: formatos Tratamento de erros:

© Copyright Trópico – Todos os direitos reservados 13

O cabeçalho tem o formato:

© Copyright Trópico – Todos os direitos reservados 14

O protocolo base provê dois tipos de serviço para as aplicações:

Autenticação e/ou autorização (authentication / autorization):

• Um comando ACR bem sucedido ativa a contabilização.

• Os registros (“accounting records”) caem em duas categorias:

© Copyright Trópico – Todos os direitos reservados 15

A comunicação entre duas entidades Diameter se inicia

O originador envia a mensagem CER (Capabilities-

Após isto, uma conexão TLS pode ser negociada.

Conexão está pronta para a troca de mensagens

Se nenhuma mensagem for trocada por algum tempo,

Cada lado pode terminar a comunicação enviando DPR

Após isto, a conexão de transporte pode ser

© Copyright Trópico – Todos os direitos reservados 16

A interface entre os AS (servidores de aplicação) e o HSS é a interface Sh. Entre os AS e o SLF é a

© Copyright Trópico – Todos os direitos reservados 17

Na comunicação entre o HSS e S-CSCF:

© Copyright Trópico – Todos os direitos reservados 18

© Copyright Trópico – Todos os direitos reservados 19

© Copyright Trópico – Todos os direitos reservados 20

Identificação da aplicação na interface Cx (Advertising Application Support):

© Copyright Trópico – Todos os direitos reservados 21

Gerenciamento de localização: registro e desregistro

• Quando o I-CSCF recebe a mensagem REGISTER de um P-CSCF:

© Copyright Trópico – Todos os direitos reservados 22

Gerenciamento de localização: registro e desregistro

• Quando o S-CSCF recebe a mensagem REGISTER do I-CSCF:

• Se, pelo gerenciamento de usuário, a rede decide suprimir o registro de um usuário:

© Copyright Trópico – Todos os direitos reservados 23

Gerenciamento de localização: busca da localização do S-CSCF

• O I-CSCF encaminha a solicitação ao S-CSCF:

© Copyright Trópico – Todos os direitos reservados 24

São utilizados os comandos Diameter definidos no protocolo base:

São utilizados os comandos Diameter definidos para a interface Cx e Dx:

© Copyright Trópico – Todos os direitos reservados 25

r = requerido, o = opcional, - = não contém).