top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

origin-host scope for diameter overload control

+1 vote
267 views

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.

posted Jun 26, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

I agree it should be optional for agents. I'm on the fence for clients, but optional is probably okay there. If people specify application specific behavior for certain applications, they could always mandate it there.

answer Jun 27, 2013 by anonymous
Similar Questions
+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)?

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

+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

I was going through rfc3588 and could not understand when a Diameter Server/Agent adds Error-Reporting -Host AVP within the answer message.

+1 vote

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

...