top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

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 LinkedIn 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

From the RFC 6733, it is clear that diameter session is identified bases on session-id, which has to be globally unique. Also in section 2.5 (Connections vs Sessions), its clearly mentioned that one connection can be used to multiplex multiple diameter sessions.

I have following questions related to diameter session -
Is there any implicit correlation between diameter session and origin-host? Does diameter standard allow different requests for the same session to have different origin-host value? Is there any possible problem if the value of Diameter Identity (part of recommended format for session-id) is different from those present in the request (like origin-host/origin-realm)?

+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 ?