Message Processing at Redirect Agent

It is often called as Redirecting Request.

As we know that Redirect Agent is generaly used  when Diameter routing configuration needs to be centralized,it does not forward message to other node, it just reply to the requesting node with route information. Does not change AVP value in message. Does not originate any message, but capable of handling any kind of messages. We can configure the redirect agent that it shall handle certain message only. Redirect Agent MUST advertise Relay Application Identifier (0xffffffff). Now lets see what all information is sent by redirect agent in following AVPs.

{ Result-Code }

 1*{ Redirect-Host }

   [ Redirect-Host-Usage]

Redirect Agent answers with Result-Code set to DIAMETER_REDIRECT_INDICATION  and E-bit of answer message shall also be set. Because DIAMETER_REDIRECT_INDICATION  comes under protocol error category. 

if Result-Code AVP is set to the Redirect-Host AVP MUST be present in answer message containing the Diameter Identity of node to which request should be forwarded.It is possible that Redirect Agent may reply with multiple Redirect-Host AVPs. Now to which node message need to be forwarded can decided by local configuration at node.  Received routing information whether to stored by node so that next time similary kind of request shall be forwarded without consulting Redirect Agent will depend on the value of Redirect-Host-Usage AVP. 

Redirect-Host-Usage AVP supports following values

DONT_CACHE                        0

The host specified in the Redirect-Host AVP should not be cached.

This is the default value. I.e. Just use the value in to forward message don't be stored at Node-1

ALL_SESSION                       1

All messages within the same session, as defined by the same value of the Session-ID AVP MAY be sent to the host specified in the Redirect-Host AVP. I.e. There is no need to consult Redirect agent for all the messages associated in considered session. Identity received shall be stored until session in question terminates. 

ALL_REALM                         2

All messages destined for the realm requested MAY be sent to the

host specified in the Redirect-Host AVP.

REALM_AND_APPLICATION             3

All messages for the application requested to the realm specified

MAY be sent to the host specified in the Redirect-Host AVP.

ALL_APPLICATION                   4

All messages for the application requested MAY be sent to the host specified in the Redirect-Host AVP.

ALL_HOST                          5

All messages that would be sent to the host that generated the

Redirect-Host MAY be sent to the host specified in the Redirect-

Host AVP.

ALL_USER                          6

All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP.

S6a/S6d [MME/SGSN <-->HSS]

Some times S6a/S6d interfaces are treated as two separate interfaces but here we treat them as single because both have same application identifier(16777251).S6a interface is between MME-HSS and S6d interface between SGSN-HSS.

This section gives abstrace of s6a/s6d interface. In LTE network HSS (Home Subscriber Server) is a database that contains Authentication Information and Subscriber's Data  such as Services associated, Location Information etc. Where MME shall take care of mobility of UE/Subscriber. This interface is used to Authenticate Subscriber, providing services to subscriber, to store location information of subscriber sent by MME.There are eight messages are exchanged between MME/SGSN and HSS. Four of them are invoked by MME and rest four are invoked by HSS.

1)AIR/AIA (Authentication-Information-Request/Answer):- MME fetches Authentication data from HSS to authenticate subscriber.

2)ULR/ULA (Update-Location-Request/Answer):- MME stores its own identity at HSS, and feteches subscription data from HSS.

3)NOR/NOA (Notification-Request/Answer):- MME stores PDN address and other attach information at HSS.

4)PUR/PUA (Purge Request/Answer):- MME informs the HSS that UE is inactive for a long period that why MME has deleted the Subscription Data received in previous ULR from its end. 

5)IDR/IDA(Insert-Subscription-Data-Request/Answer):- It is invoked by HSS only when a subscriber is attached and there is change in subscriber profile at HSS end then same change to be reflected at Subscriber profile at MME (sent in ULA) end as well.

6)DSR/DSA (Delete-Subscriber-Data-Request/Answer):- It is invoked by HSS only when Subscriber is attached and some data is deleted at HSS. Now HSS informs MME with this message that some part of subscription data is deleted at HSS.

7)CLR/CLA(Cancel-Location-Request/Answer):- Invoked by HSS to detach the subscriber.

8)RSR/RSA(Reset-Request/Answer):- Invoked by HSS, to inform MME that HSS goes down for some time, kindly sync the data and send fresh location/PDN information at HSS.

Detail behavior with example

1. AIR/AIA (Authentication-Information-Request/Answer)

2. ULR/ULA (Update-Location-Request/Answer)

3. NOR/NOA (Notification-Request/Answer)

4. PUR/PUA (Purge Request/Answer)

5.    IDR/IDA(Insert-Subscription-Data-Request/Answer)

6. DSR/DSA (Delete-Subscriber-Data-Request/Answer)

7. CLR/CLA(Cancel-Location-Request/Answer)

8. RSR/RSA(Reset-Request/Answer)

Your Comments /Suggestions and Questions are always welcome. I would try to clear your doubts with best of my knowledge. So feel free to put Questions.

Diameter Message Processing

For deep under standing of this section please read following at least once more
1)Diameter Message Structure and Message Flow
2)Peer Table
3)Realm Routing Table

In diameter a message can be a request or an answer message, here we will see how these messages are sent to there destinations with the help of Peer Routing table and Realm Routing table. Diameter message reaches to final destination with proper combination of Destination-Host and Destination-Realm.

Here first we look for how request message is routed to its destination.

There are three valid combination that are supported by diameter, by which message shall reach to destination in given scenario.

1) Neither Destination Realm nor Destination host is required.
The request that shall not be proxied MUST NOT contain Destination-Host and Destination-Realm AVPs. Only request message comes in this scenario is CER message. Destination-Host and Destination-Realm AVPs are not in CER ABNF.

 <CER> ::= < Diameter Header: 257, REQ >
                { Origin-Host }
                { Origin-Realm }
             1* { Host-IP-Address }
                { Vendor-Id }
                { Product-Name }
                [ Origin-State-Id ]
              * [ Supported-Vendor-Id ]
              * [ Auth-Application-Id ]
              * [ Inband-Security-Id ]
              * [ Acct-Application-Id ]
              * [ Vendor-Specific-Application-Id ]
                [ Firmware-Revision ]
              * [ AVP ]

Why it is so? Because CER is the first message exchange between any two nodes as soon as transport connection is established that's why there no need of Destination-Host and Destination-Realm AVPs. It is exchanged between nodes that have direct connection, Suppose there is relay in between client and server then there shall be two CER messages (Instance Client to relay, another is relay to server).

2)Contains Destination Realm MUST Not Destination-Host

When request is sent to a server of an application serving a complete realm. Because Destination-Host can easily identified by checking application identifier in Realm-Routing Table of intermediate nodes.

3)Must contain both Destination-Host and Destination-Realm

When there are more than one server is serving a realm then to which server request to be send is identified by Destination-Host AVP. When server wants to send request to a specific client then server should add Destination-Host and Destination-Realm AVPs. 

Diameter Load Balancing 

The Destination-Realm AVP MUST be present if the message is   proxiable.  Request messages that may be forwarded by Diameter agents(proxies, redirects or relays) MUST also contain an Acct-Application-Id AVP, an Auth-Application-Id AVP or a Vendor-Specific-Application-Id AVP. Because Application Identifier is act as secondary key in Realm Routing Table, shall be use to find next node/hop for request.

A message that MUST NOT be forwarded by Diameter agents (proxies, redirects or relays) MUST not include the Destination-Realm in its ABNF. Because without realm diameter agents can't search realm routing table.

The value of the Destination-Realm  AVP MAY be extracted from the User-Name AVP, or other application-specific methods. This strategy can be used for load balancing, by sending the request to one or more servers on the basis of avp values.

For instance: User-Name AVP  contains a unique identification number for a user then we have an option to divide the load on the basis of value. I.e. 1 to 1000 shall go to server1 1000-2000 shall go to server to etc.

If none of the above is the case then,answer is returned with the Result-Code set to DIAMETER_UNABLE_TO_DELIVER, with the E-bit set.

Processing of request 
1)Request reaches to server
a) If Destination-Host Identity matches which Local Identity (Node URI). It means that this message is destined to this node only and it has reached its destination.
b) If Destination-Host is not persent then it check that Destination-Realm persent matches with its own Realm and In Realm Routing Table it is mentioned  (LOCAL )that to be consumed locally for given application Identifier.
c)If both Destination-Host and Destination-Realm is not persent then it should be consumed locally by every node including servers because it's CER message received from peer.

2)Request Forwarding
When a node checks that Destination-Host received in request is present in PEER Table then node shall forward the request to its peer.

3)Request Routing
When Destination-Host present in request in not perent PEER table or Destination-Host AVP is not persent in request then decission where to send request shall be done using application Identifier and Realm routing table.

Diameter Interfaces in LTE (EPC)

Evolved Packet Core majorly have 5 nodes.
1) Mobility Management Entity (MME)
2) Home Subscriber Server (HSS) 
3) Serving Gateway (S-GW)
4) PDN Gateway (P-GW)
5) Policy and Charging control entity/Function (PCRF)

These nodes interact then uses diameter based interfaces.

Dark Lines shows the major Diameter Interfaces in EPC.

Some times CSS data is not stored at HSS then S7a interface is used to communicated with MME. S7a is also diameter based interface

Diameter Agents

Diameter defines a specific role for each of its agents, Following agents are in diameter.
1)Diameter Relay (DRA)
2)Diameter Proxy
3)Diameter Redirect 
4)Translator

1) Diameter Relay 
It is used to rout the message to other diameter node with the help of  routing information received in message such as Destination-Realm, Destination -Host. Relay can accept the request with multiple networks.
Relay must not change message format and avps except the routing avps. Relay must advertise its Application Identifier (0xffffffff).

2)Diameter Proxy
Diameter Proxy does all that relay does. Moreover proxy can change message and avp format if required to apply some policies.
A Diameter Proxy MUST be called as DIAMETER X Proxy, where X is the application whose messages are being proxy-ed by by the node.


3)Diameter Redirect
Diameter Redirect agent is useful in the scenario where diameter routing information is stored at centralized location. Every node can get the rout information from Redirect agent and then forward the message. Redirect Agent does not forward message to any node. It just replies to the request received with the routing information.[Message Processing at Redirect Agent]
Redirect must advertise its Application Identifier (0xffffffff)

4)Translator
Translator changes RADIUS message to Diameter and vice-versa for backward compatibility.