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

Facebook Login
Site Registration

Question regarding correlation of diameter session and origin-host?

+1 vote
51 views

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

posted Jun 29, 2017 by anonymous

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

1 Answer

0 votes

Only what is spelled out in the RFC "The Session-Id MUST begin with the sender's identity [...]"

A dubious diameter implementation may decode the session-id extracting what the origin-host might be. But that would be silly since it is already present in the origin-host AVP. Well-behaved diameter implementations treat session-id as an opaque string.

Does diameter standard allow different requests for the same session to have different origin-host value?
Yes, eg RAR and ASR requests will have a typically have an origin-host/realm different from where the session-id was created.

answer Jun 29, 2017 by Luv Kumar
Similar Questions
+1 vote

There are use cases for Diameter overload control where it would be useful for a server to be able to throttle traffic from a specific source. When the source is adjacent to the server, this can be accomplished easily enough by the server just sending the overload control information directly to the source in question.

However, when there are intermediaries between the server and the source (client), the current mechanism a way to do this. Adding a scope for origin-host would solve this issue. The way this would work would be for the server to construct the overload control information and attach the origin-host scope to it that matches the specific source of overload it wants to target. The information would be ignored by any other recipients as they would not have an origin-host that matches that scope when sending messages.

I think this could be an optional scope as it wouldn't be needed for all applications that may use Diameter overload control.

+2 votes

In case of multiple OCS node with multiple PCRF/PCEF how correlation happen over multiple interface? i.e. how a user call terminate on a specific node.

+3 votes

I have a query regarding usage of Origin-State-Id AVP in Diameter. The Diameter Base Protocol RFC 3588 says that Origin-State-Id AVP MAY be included in any diameter message.

Now, some diameter based application (like a 3GPP defined application) defines new commands and in those commands’ ABNF Origin-State-Id AVP is not present.

Then does this imply that Origin-State-Id AVP MUST not be sent in these commands or it can be sent because RFC 3588 says it can be sent in any diameter message?

+1 vote

Can someone please explain why few "request" message contains Destination-Host and Destination-Realm AVPs and few of them not ?

+3 votes

I am trying to clarify the allowed naming convention for the host and realm of a diameter node. This relates to the values used in the Origin-Host AVP (AVP Code 264) and Origin-Realm AVP (AVP Code 296). I have reviewed the Diameter RFCs and cannot find a definitive answer to this issue.

The reason for asking this question is that I am in discussion with a vendor of a Diameter Routing Agent (DRA) which claims that the host of a diameter node has to be in the format host.realm.
(1) Example of the only allowed format according to the vendor:Origin-Realm: example.com
Origin-Host: node.example.com
I want to clarify if multiple subdomains are allowed to be added in the host without being present in the realm.(2) Example:Origin-Realm: example.com
Origin-Host: node.site1.example.com

According to the vendor, the example 2 is not allowed. To have the host as in example 2, the realm will have to be site1.example.com.
Could someone please clarify this naming issue or point me to the standard where this is defined.

Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...