top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

Question On Proxy-Info AVP of diameter stack

+2 votes

In a heterogeneous architecture of diameter stack where the actual stack runs on a network front-end machine, with diameter application (eg., HSS) running on the back-end machines. So far this front-end network stack was stateful i.e. if it had sent an outgoing request, it knew to which back-end machine the response has to be routed to.

This state-full property brings-in some issues and thus we're planning on to make the network front-end stack stateless. For this, we need the ability to have some information to be put in the request with the guarantee that the same will be returned in the response - basically the state information. For stateless agents, RFC already defines the Proxy-Info AVP for storing and retrieval for their state information. There has been suggestion to use the same for a new outgoing - not forwarded - requests. We know that AVP name itself implies that only agents can utilize them. But, can this be possible to use this AVP for new outgoing request to store the stateless information? Is this practiced anywhere? How do the popular implementation of stack/diameter application deal with a 'Proxy-Info' AVP without let's say a Route-Record AVP - i.e. Only if Route-Record AVP is present, it means it has passed through an agent?

Any thoughts.

posted Jul 26, 2013 by Salil Agrawal

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

+1 vote

Not sure if I understand the configuration correctly. You say request is outgoing, but not forwarded. Probably all requests from the front-end machine get sent to the same relay. If this is the case, from the perspective of that relay, this is going to be just like any other PDU coming from any other peer.

With that assumption, I am sure that you can use Proxy-Info AVP for this purpose. Any downstream peer is required to return this AVP in the answer, irrespective of Route-Record. So at each node, the decision would be "if Proxy-Info AVP is present, if it is for me, let me remove and use it, otherwise pass it back in the answer". It will be incorrect for any node not to pass it back.

answer Jul 26, 2013 by Rathnakumar Kayyar
Thanks that should serve the purpose...
Similar Questions
+4 votes

When I come across the S6a interface we are using IMEI AVP for International Mobile Equipment Identity.

But when I come across the Gy interface we are using a Grouped AVP named as User-Equipment-Info AVP which contain User-Equipment-Info-Value and User-Equipment-Info-Type.

My query is why we need to use two different Diameter AVPs across the EPC network which gives the same result , let say IMEI in this case.

+1 vote

I am not able to understand the significance of this AVP from rfc3588. Can someone please explain in simple word ?

+2 votes

What are the encrypted AVPs and significance of these. How encryption is enabled between the two diameter nodes ? Is there any separate message to enable encryption between the nodes ?

+2 votes

Please find the description of the problem:
A diameter client and server communicates in the network through Proxy Agent.
Here, I have assumed PCEF is a diameter client and PCRF is a diameter server. Interface between the PCEF and the PCRF is known as Gx.

Does Proxy agent, which sits between PCEF and PCRF, need to support Gx application ?
Does Proxy agent validate presence of any mandatory or optional AVP when it receives a message from a diamter client (PCEF) before forwarding it to diameter server (PCRF) ?

Can someone please provides the detailed behavior of a proxy agent ?

Useful Links with Similar Problem
Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.