Os AVPs (Attribute-Value Pairs) transportam todos os dados DIAMETER. Cada um tem um AVP Code, um octeto de flags (V vendor, M mandatory, P reservado), um comprimento, um Vendor-Id opcional e um valor tipado. Os valores usam tipos base como Unsigned32, OctetString, Address, Time, Enumerated e Grouped. Os AVPs Result-Code e Experimental-Result reportam resultados.
Estrutura do AVP
Cada elemento de dados DIAMETER — identidades, campos de subscrição, quotas, resultados — é codificado como um AVP. Um AVP começa com um AVP Code de 32 bits, depois um octeto de flags, um comprimento de 24 bits que cobre todo o AVP, um Vendor-Id opcional de 32 bits, e o valor preenchido até uma fronteira de 4 octetos. O AVP Code sozinho é único dentro do espaço gerido pela IETF; quando a flag V (Vendor-Specific) está definida, o código é interpretado dentro do espaço de numeração do Vendor-Id que se segue — é assim que o 3GPP (Vendor-Id 10415) define as centenas de AVPs usados por S6a, Gx e Cx sem colidir com o protocolo base.
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code (32) |
| V M P r r r r r| AVP Length (24) |
| Vendor-Id (32) — present only if V=1 |
| Data ... (padded to a 4-octet boundary) |As flags V, M e P
Três flags de AVP governam como um recetor deve tratar o AVP. V (Vendor-Specific) assinala que se segue um Vendor-Id e que o AVP Code vive no espaço desse vendor. M (Mandatory) é a mais importante: se M estiver definida e o recetor não compreender o AVP, deve rejeitar toda a mensagem com DIAMETER_AVP_UNSUPPORTED (5001) — pelo que definir M erradamente quebra o interworking, e os AVPs de vendor que uma implementação pode ignorar em segurança são enviados com M apagada. P foi originalmente um marcador de segurança end-to-end; a RFC 6733 desaconselhou esse uso e o bit está agora reservado e definido a zero.
| Flag | Nome | Significado quando definido |
|---|---|---|
| V | Vendor-Specific | Existe um campo Vendor-Id; o código está no espaço desse vendor |
| M | Obrigatório | O destinatário deve entender ou rejeitar a mensagem (5001) |
| P | (reservado) | Anteriormente segurança de ponta a ponta; obsoleta pela RFC 6733, definida como 0 |
Tipos de dados base
Os valores de AVP são fortemente tipados. A RFC 6733 define um conjunto de tipos básicos e vários tipos derivados construídos a partir de OctetString. Os tipos integer e unsigned transportam contadores, identificadores e enumerações; OctetString transporta binário opaco ou estruturado; e os tipos derivados acrescentam semântica que uma implementação pode validar. Address codifica um endereço IP com uma família de endereço de dois octetos à frente. Time é uma contagem de segundos de 32 bits ao estilo NTP. Enumerated é um Integer32 cujos valores são nomeados pela aplicação. DiameterIdentity e DiameterURI transportam FQDNs e URIs de pares.
| Tipo | Codificação | Uso típico |
|---|---|---|
| Unsigned32 / Integer32 | Inteiro de 32 bits | Contadores, quotas, Auth-Application-Id, Result-Code |
| Unsigned64 / Integer64 | Inteiro de 64 bits | Volumes em octetos, contadores grandes |
| OctetString | Octetos opacos | Payloads binários (vetores de autenticação, TPDUs) |
| UTF8String | OctetString | Texto legível por humanos (User-Name, nome do produto) |
| Enumerated | Integer32 | Conjuntos de valores nomeados (ex: RAT-Type, CC-Request-Type) |
| Address | OctetString + família | Endereços IPv4/IPv6 (Host-IP-Address, Framed-IP) |
| Hora | Unsigned32 | Segundos desde 1900 (Event-Timestamp) |
| DiameterIdentity | OctetString | FQDN do par (Origin-Host, Destination-Host) |
| Grouped | AVPs aninhados | AVPs que contêm outros AVPs |
Grouped AVPs
Um Grouped AVP tem, como o seu valor, uma lista concatenada de outros AVPs — pelo que registos estruturados aninham-se de forma limpa sem novas regras de fio. Subscription-Data em S6a, Charging-Rule-Install em Gx e Experimental-Result transportam todos sub-AVPs dentro de um grupo. O agrupamento é recursivo: um Grouped AVP pode conter mais Grouped AVPs, o que é como um perfil de subscrição LTE completo ou um conjunto de regras PCC é expresso como um único AVP de topo. Cada AVP contido mantém o seu próprio código, flags e comprimento, pelo que um recetor analisa o grupo com a mesma maquinaria que usa no nível de topo.
Result-Code e Experimental-Result
O DIAMETER reporta o resultado de um request na answer. O AVP base Result-Code (código 268) é um Unsigned32 agrupado em intervalos pelo dígito inicial: 1xxx informativo, 2xxx sucesso, 3xxx erros de protocolo (de um proxy/relay), 4xxx falhas transitórias que o cliente pode repetir, e 5xxx falhas permanentes. Quando uma aplicação precisa de um erro específico de vendor que o Result-Code base não consegue exprimir, usa o AVP Experimental-Result (código 297) — um Grouped AVP que transporta um Vendor-Id mais um Experimental-Result-Code — que é como o 3GPP sinaliza erros como DIAMETER_ERROR_USER_UNKNOWN ou DIAMETER_ERROR_ROAMING_NOT_ALLOWED.
| Intervalo | Classe | Exemplo |
|---|---|---|
| 1xxx | Informativo | 1001 DIAMETER_MULTI_ROUND_AUTH |
| 2xxx | Sucesso | 2001 DIAMETER_SUCCESS |
| 3xxx | Erro de protocolo (proxy) | 3002 UNABLE_TO_DELIVER, 3007 APPLICATION_UNSUPPORTED |
| 4xxx | Falha transitória (tentar novamente) | 4181 AUTHENTICATION_DATA_UNAVAILABLE (3GPP) |
| 5xxx | Falha permanente | 5001 AVP_UNSUPPORTED, 5012 UNABLE_TO_COMPLY |
Perguntas frequentes
O que é um AVP no DIAMETER?
Um AVP (Attribute-Value Pair) é a unidade de dados em cada mensagem DIAMETER. Transporta um AVP Code, um octeto de flags (V, M, P), um comprimento, um Vendor-Id opcional e um valor tipado. Todas as identidades, campos de subscrição, quotas e resultados são codificados como AVPs, e uma mensagem é um cabeçalho seguido por uma lista deles.
O que faz a flag M (Mandatory)?
Se a flag M estiver definida e o recetor não compreender esse AVP, deve rejeitar toda a mensagem com DIAMETER_AVP_UNSUPPORTED (5001). Os AVPs que um par pode ignorar em segurança são, por isso, enviados com M apagada. O uso incorreto do bit M é uma causa comum de falhas de interworking entre vendors.
O que é um Grouped AVP?
Um Grouped AVP é um AVP cujo valor é ele próprio uma lista de AVPs, permitindo que registos estruturados se aninhem. Subscription-Data, Charging-Rule-Install e Experimental-Result são Grouped AVPs. O agrupamento é recursivo, pelo que um perfil de subscrição LTE completo ou um conjunto de regras PCC pode ser transportado como um único AVP de topo.
Como são identificados os AVPs específicos de vendor?
Pela flag V mais um campo Vendor-Id. Quando V está definida, um Vendor-Id de 32 bits segue-se ao comprimento e o AVP Code é interpretado dentro do espaço de numeração desse vendor. O 3GPP usa o Vendor-Id 10415 para definir os AVPs para S6a, Gx, Cx e as outras interfaces de aplicação.
Qual é a diferença entre Result-Code e Experimental-Result?
O Result-Code (AVP 268) transporta os códigos de resultado base da IETF agrupados como 1xxx/2xxx/3xxx/4xxx/5xxx. O Experimental-Result (AVP 297) é um Grouped AVP com um Vendor-Id e um Experimental-Result-Code, usado quando uma aplicação precisa de um erro específico de vendor como o DIAMETER_ERROR_USER_UNKNOWN do 3GPP.
O que significam os intervalos de result-code do DIAMETER?
1xxx é informativo, 2xxx é sucesso (2001 DIAMETER_SUCCESS), 3xxx é um erro de protocolo normalmente levantado por um proxy, 4xxx é uma falha transitória que o cliente pode repetir, e 5xxx é uma falha permanente. O dígito inicial diz ao cliente se deve repetir, falhar ou reencaminhar.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.