top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Question regarding correlation of diameter session and origin-host?

+1 vote
480 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 LinkedIn 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
origin-host scope for diameter overload control

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
Diameter correlation over multiple Interfaces

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
Origin State AVP in Diameter Protocol

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?

+3 votes
Regarding RFC6942 Diameter Support for ERP

I was reading 6696 and 6942 (it's been awhile) and I need clarification:

1) It appears that 6942 does not support transportation of DSRK key. Only rRK and rMSK. Is that correct?

2) According to RFC 6696 - section 4.2:

RFC 6696: Section 4.2:

"The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity."

So why is 6942 transporting the rRK around?

+1 vote
DIAMETER: Why DPR and DPA messages don't contain Destination-Host and Destination-Realm AVPs ?

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

...